LLM 환각 줄이는 프롬프트 제약 체크리스트: 용어·근거·형식 3가지만 고정하라
최종 수정: 작성자: Finyul
LLM 환각 줄이는 프롬프트의 핵심은 “더 길게 설명하기”가 아니라 제약(Constraints)을 먼저 박는 것입니다. 특히 트레이딩/리서치처럼 그럴듯하게 틀리면 치명적인 영역에서는, 용어·근거·형식 3가지를 고정하는 것만으로 출력 품질이 확 안정됩니다.
전체 폐루프(분석→예측→결정→실행) 설계가 궁금하다면 LLM 멀티에이전트 투자 시스템(MAS) 완전 가이드를 참고하세요.
환각이 왜 생기고, 트레이딩에서는 왜 더 위험한가
환각(Hallucination)의 정의
- 환각: “모르는 걸 모른다고 말하지 못하고” 그럴듯한 답을 만들어내는 현상
- 트레이딩에서는 이게 숫자/근거/규칙으로 포장되면서 더 위험해집니다.
트레이딩 맥락에서의 구체적 사례(근거·수치·형식 환각):
- 존재하지 않는 공시/뉴스를 “봤다”고 말함
- 확률 합이 1이 아닌데도 “정확하다”고 단정
- 허용되지 않은 포지션 액션을 만들어냄(예:
increase_30)
실전 설계에서 이미 답을 보여준 연구
중국 공모 REITs 대상 멀티에이전트 트레이딩 연구(arXiv:2602.00082)는 명시적 프레임워크 + 용어 제약 + 구조화 출력을 전제로 시스템을 설계합니다. 특히
- 저변동 시장을 위해 동적 임계값 파라미터를 고정: Nv≈30일, qL/qU=30%/70%, τhigh≈1.4, τlow≈0.7
- 해당 설정에서 약 33% 거래일이 sideways(횡보)로 분류(=횡보는 정상 범주)
- 의사결정은 이산 액션 7개로 제한: close, reduce 40/20, hold, increase 20/40, upper limit
이게 바로 “용어·근거·형식”을 먼저 고정해야 하는 이유입니다.
체크리스트 핵심: 용어·근거·형식 3가지 제약만 고정하면 된다
1) 용어 고정(Glossary / Enum)
허용 라벨만 쓰게 해라(라벨 흔들림 차단)
실전 체크
- horizon은 T1/T5/T20만
- action은 7개 enum만
예시: action: close, reduce_40, reduce_20, hold, increase_20, increase_40, increase_upper_limit
2) 근거 강제(Evidence)
근거 없으면 말하지 말게 해라(내용 환각 차단)
실전 체크
- claim마다 evidence 최소 1개
- evidence.ref는 재조회 가능한 키
예시: evidence.ref: arXiv:2602.00082 (sideways 파라미터 근거)
3) 형식 강제(Strict JSON + Validation)
오직 JSON + 검증 실패 시 HOLD(운영 사고 차단)
실전 체크
- 확률(up/down/side) 합 검증
- enum 위반/필드 누락 시 HOLD
예시: 거래비용 0.03%(0.0003) 가정도 JSON으로 고정 기록
경계(금지행동) / 계약(JSON) / 검증(Validation)
1) 용어 제약: “허용 단어/라벨”을 미리 정의한다
환각의 많은 부분은 라벨 흔들림에서 시작합니다(같은 의미를 다른 말로 표현 → 파서/검증 붕괴).
용어 제약 체크
- [ ] 라벨은 enum으로 고정했나? (예: claim=positive/neutral/negative)
- [ ] 호라이즌을 고정했나? (예: T1/T5/T20)
- [ ] 액션을 고정했나? (예: close, reduce_40/20, hold, increase_20/40, upper_limit)
- [ ] 금지 단어를 명시했나? (예: “확실”, “무조건”, “100%”, “보장”)
| 필드 | 허용값(enum/범위) | 정의(의미) | 비고(금지/주의) |
|---|---|---|---|
| horizon | T1, T5, T20 | 예측 기간(1/5/20 거래일) | 다른 키 금지 |
| direction | up, down, side | 방향 라벨 | side=횡보(정의 필요) |
| claim | positive, neutral, negative | 분석 결론 라벨 | 근거 없으면 금지 |
| action | close, reduce_40, reduce_20, hold, increase_20, increase_40, increase_upper_limit | 의사결정 이산 액션 | enum 외 금지 |
| Nv_days | 30(about) | 단기 변동성 윈도우 | 출처 고정(arXiv) |
| qL/qU | 0.30 / 0.70 | 분위 경계(30%, 70%) | 고정 값 기록 |
| tau_high / tau_low | 1.4 / 0.7 (approx) | 변동성 레짐 임계 | 고정 값 기록 |
| sideways_rate | ~33% | 횡보 비중(설정 결과) | “정상 범주”로 취급 |
| transaction_cost_rate | 0.0003 (=0.03%) | 거래비용 가정 | 로그에 항상 남김 |
| confidence | 0~1 | 신뢰도 | 과신 금지(단정 표현 금지) |
복붙 프롬프트(용어 제약)
너는 트레이딩 시스템의 에이전트다. 아래 '허용 라벨'만 사용하라.
[허용 라벨]
- horizon: T1, T5, T20
- direction: up, down, side
- action: close, reduce_40, reduce_20, hold, increase_20, increase_40, increase_upper_limit
- claim: positive, neutral, negative
[금지]
- 위 목록에 없는 라벨/액션을 만들어내지 마라.
- "확실/무조건/보장" 같은 단정 표현 금지.
- 근거 없는 숫자(가격/수익률/지표) 생성 금지.2) 근거 제약: “근거 없으면 말하지 말라”를 룰로 박는다
트레이딩에서 환각은 대부분 근거가 비어 있는데 결론이 나오는 것입니다.
근거 제약 체크
- [ ] 모든 claim에 evidence가 최소 1개 붙는가?
- [ ] evidence는 “재조회 가능한 ref”인가? (문서ID/기사ID/데이터스냅샷키)
- [ ] 근거가 부족하면 “insufficient_evidence”로 떨어지는가?
- [ ] 추정/가정은 “assumption”으로 따로 표기하는가?
| 규칙 | 최소 기준 — 좋은 예 | 실패 시 처리(폴백/플래그) |
|---|---|---|
| 근거 최소개수 | evidence ≥ 1evidence:[{source:"paper",ref:"arXiv:2602.00082"}] | insufficient_evidence + HOLD |
| 근거 재조회 가능 | ref는 문서/데이터 키ref:"Table1" 또는 "Section2.1" | ref 없으면 재생성 |
| 숫자 포함 시 근거 필수 | 수치 언급 시 evidence 필수"거래비용 0.03%(0.0003)" + ref | 근거 없으면 수치 삭제 |
| 추정/가정 분리 | assumption 필드로 분리assumption:["데이터 누락 가능"] | 사실처럼 단정 금지 |
| 출처 유형 제한 | paper/disclosure/news/price/macro만source:"disclosure" | 허용 source 외 금지 |
복붙 프롬프트(근거 제약)
[근거 규칙]
- 모든 결론(claim/rationale)은 evidence 배열(최소 1개)을 동반해야 한다.
- evidence.ref는 재조회 가능한 키여야 한다(예: disclosure_id, news_id, dataset_key).
- 근거가 없으면 claim을 만들지 말고 "insufficient_evidence"로 표시하라.
- 추정은 assumption 필드에만 쓰고, 사실처럼 단정하지 마라.3) 형식 제약: “오직 JSON” + “스키마 검증 실패 시 폴백”을 강제한다
형식이 흔들리면, 좋은 내용도 운영에서 쓰레기가 됩니다. 가장 강력한 환각 방지책은 형식 강제입니다.
형식 제약 체크
- [ ] 출력은 “오직 JSON”인가? (추가 문장 금지)
- [ ] 필수 필드를 required로 고정했나?
- [ ] 확률합/enum 등 도메인 검증 룰이 있는가?
- [ ] 실패 시 기본값이 HOLD인가? + 사유 로그 남기는가?
LLM 에이전트 출력 표준화: JSON 스키마 템플릿으로 분석→예측→결정 연결하기를 참고하세요.
복붙 프롬프트(형식 제약: Strict JSON)
출력은 반드시 '오직 JSON'이어야 한다. 추가 텍스트 금지.
JSON 파싱이 불가능하면, 아래 에러 JSON만 출력하라:
{"status":"error","reason":"json_parse_failed"}
[필수 필드]
- schema_id, run_id, as_of, asset.code
- (예측) horizons.T1/T5/T20, up/down/side
- (결정) action(enum), rationale[], constraints_applied[]
[도메인 검증]
- up+down+side=1 (오차 ±0.001 허용)
- action은 enum 7개 중 하나
검증 실패 시:
{"status":"hold","reason":"validation_failed","failed_rule":"..."}“검증 질문(Verification Prompts)” 3개만 추가하면 과신이 크게 줄어든다
모델이 답을 낸 뒤, 스스로 검증하게 만드는 질문을 한 번 더 거치면 과잉확신이 줄어듭니다.
- 근거 매핑 질문: “각 claim에 어떤 evidence가 붙었는지 1:1로 매핑해라”
- 불확실성 질문: “근거가 부족한 항목 3개를 찾아 null/unknown 처리해라”
- 형식 체크 질문: “확률 합=1, enum 위반 여부를 스스로 체크해라”
| 목적 | 검증 질문(프롬프트) | 체크 항목 | 실패 시 조치 |
|---|---|---|---|
| 근거 매핑(1:1) | 각 claim마다 evidence.ref를 1:1로 매핑해서 표로 출력해라. evidence 없는 claim은 삭제하라. | evidence 누락 여부 | evidence 없으면 insufficient_evidence + HOLD |
| 불확실성 표기 | 확신할 수 없는 항목 3개를 찾아 unknown으로 표시하고, 단정 표현을 제거하라. | ‘확실/무조건/보장’ 제거 | 과신 지속 시 모델 재시도 |
| 형식/규칙 점검 | 확률 up/down/side의 합이 1인지, action이 enum 7개 중 하나인지 검증 결과를 JSON으로 출력해라. | sum_to_one, enum_ok | 실패 시 {"status":"hold","reason":"validation_failed"} |
이 체크리스트의 한계와 안전장치
- 프롬프트 제약은 환각을 줄일 뿐 ‘0’으로 만들지 못합니다.
- 데이터 자체가 틀리거나(뉴스 오보/지표 계산 오류) 입력이 부족하면, 모델은 “정직하게 모른다”를 말하도록 설계해야 합니다.
- 트레이딩에 적용할 경우, 실행은 규칙 엔진(검증 게이트)가 맡아야 합니다(LLM 텍스트를 바로 주문으로 번역 금지).
참고
- NIST AI Risk Management Framework (AI RMF 1.0)
- JSON Schema (Draft 2020-12)
- RFC 8259 (JSON 표준)
FAQ
자주 묻는 질문
- 프롬프트를 길게 쓰면 환각이 줄지 않나요?
- 길이보다 제약의 명확성이 중요합니다. "허용 라벨/근거 규칙/형식" 3개만 고정해도 체감이 큽니다.
- function calling을 쓰면 환각이 없어지나요?
- 형식 환각은 크게 줄지만, 내용 환각(근거 없는 주장)은 남습니다. 그래서 근거 제약 + 검증 질문이 같이 필요합니다.
- 확률합=1을 스키마로 강제할 수 있나요?
- JSON Schema만으로 완벽 강제는 어렵습니다. 도메인 검증(런타임 체크)를 별도로 두는 게 안전합니다.
- 트레이딩에서 가장 중요한 금지 규칙 1개만 꼽는다면?
- "근거 없는 숫자 생성 금지"입니다. 근거(ref)가 없으면 null/insufficient로 떨어지게 하세요.
결론: 환각은 “더 똑똑한 모델”이 아니라 “제약 3개”로 줄인다
- 용어 고정(enum/금지표현) → 라벨 흔들림 차단
- 근거 강제(evidence 없으면 결론 금지) → 내용 환각 차단
- 형식 강제(Strict JSON + 검증 실패 시 HOLD) → 운영 실패 차단
다음 단계(폐루프 전체 설계)가 필요하면 LLM 멀티에이전트 투자 시스템(MAS) 완전 가이드를 참고하세요.