AI가 데이터를 지어내는 것을 어떻게 막나
데이터층, 계산층, 표현층 세 층으로 쪼개고 여기에 필드 분해 → 도구 계산 → 답변 인용이라는 3단 워크플로를 붙인다. 숫자는 데이터 시스템에서 조회하고, 계산은 코드가 실행하며, 모델은 구조화된 결과를 읽을 수 있는 리포트로 쓰는 일만 담당한다. 데이터가 없으면 결손을 표기하거나 되묻지, 절대 지어내지 않는다.
한 문장 총강: 숫자는 데이터 시스템에서 와야지 모델의 머릿속에서 나오면 안 된다.
표면은 환각을 묻지만 실제로는 사실 사슬을 묻는다
| 표면상 묻는 것 | 환각 |
|---|
| 실제로 묻는 것 | 사실 사슬(事實鏈路) |
| Prompt가 할 수 있는 것 | 표현을 제약 |
| Prompt가 할 수 없는 것 | 근거 없이 숫자 증거를 보증 |
분업 원칙
데이터 도구 — 조회, 계산
모델 — 이해, 조직, 설명
1. 필드 분해
사실 숫자 — 반드시 데이터 소스와 기준(口徑)에 바인딩
폴백 규칙: 데이터가 없으면 결손을 표기하거나 되묻고, 지어내면 안 된다.
경계: 모델은 표현을 담당하지 사실을 발명하지 않는다.
2. 도구 계산
규칙: 모델이 쿼리 계획을 생성하는 것은 되지만, 결과는 결정론적 도구가 반환해야 한다.
- 전년 대비
- 전기 대비
- 순위
- 평균값
- 이상 탐지
중요한 숫자에 대해서는 2차 검증도 해야 한다.
3. 답변 인용
주보 핵심 수치 85.4% ──┬─→ 하위 쿼리 결과
└─→ 원본 리포트 링크
모든 핵심 수치는 밑바탕 출처로 역추적할 수 있어야 한다.
사용자가 「이 전환율은 어떻게 계산한 건가요?」라고 되물으면, 시스템이 기준과 출처를 제시할 수 있어야지 모델이 다시 설명하게 하면 안 된다.
- 모든 숫자에 출처가 있다
- 모든 계산에 기준이 있다
- 모든 결손에 사유가 있다
3층 아키텍처
| 층 | 누가 실행하나 | 직책 |
|---|
| 데이터층 | 업무 시스템 | 데이터 조회 |
| 계산층 | 코드 | 계산 실행 |
| 표현층 | 모델 | 구조화 결과를 읽을 수 있는 리포트로 작성 |
핵심 통찰
- 「모델이 숫자를 지어낸다」는 모델 문제가 아니라 아키텍처 문제다 — 이 문서에서 가장 중요한 재정의다. 환각을 모델 탓으로 돌리면 해법이 Prompt 조정밖에 안 되지만, 「숫자에 사실 사슬이 없다」 탓으로 돌리면 해법이 공학화 가능한 3층 분할이 된다. 답변의 분수령이 바로 이 귀인 단계에 있다.
- Prompt는 표현층의 제약기이지 사실층의 보증기가 아니다 — 이것이 Prompt 공학의 능력 상한을 제시한다. 모델이 「지어내기를 거부하게」 만들 수는 있어도 모델이 「정답을 알게」 만들 수는 없다. Prompt를 데이터베이스로 여기는 것은 제약기를 데이터 소스로 오용하는 것이다.
- 모델이 쿼리 계획을 생성하는 것은 되지만 결과를 생성하는 것은 안 된다 — 이 경계가 극히 실용적이다. 모델의 강점은 자연어 의도를 쿼리 의도로 번역하는 것(계획 생성)이고, 약점은 결정론적 연산을 실행하는 것이다. 「계획은 모델이, 결과는 도구가」를 고수하기만 하면 환각의 주입 지점이 물리적으로 격리된다.
- 「1200을 어떻게 서술할까」는 모델의 몫이고 「1200이 얼마인가」는 데이터베이스의 몫이다 — 숫자 하나로 직책 경계를 관통해 설명한다. 모든 AI 생성류 시스템에 그대로 옮길 수 있는 기준이다: 서술권은 모델에, 취득권은 데이터에.
- 기준이 불명확하면 「하나 추측하기」가 아니라 「반드시 되묻기」다 — 대부분의 AI 리포트 사고는 잘못 계산한 것이 아니라 계산 기준이 사람의 생각과 다른 것이다(테스트 계정을 포함하는지, 중복을 제거하는지, 자연주인지 롤링 7일인지). 「기준 불명확 → 되묻기」를 하드 규칙으로 만드는 편이 사후에 숫자를 맞춰보는 것보다 싸다.
- 검증 가능성은 내장할 수 있다: 총계 = 항목의 합, 주기가 완전한가 — 이 두 가지는 비용 0의 자가 점검 불변식이다. 어떤 리포트 시스템이든 이런 항등식을 어서션으로 만들어 「예쁘지만 틀린 주보」가 발송 전에 차단되게 해야 한다.
- 인용이 있어야 신뢰도가 있다: 숫자는 쿼리나 리포트 링크로 역추적 가능해야 한다 — 인용은 사용자에게 보여주기 위한 것만이 아니라 동시에 시스템 자신을 위한 감사 입구다. 역추적 가능한 숫자는 문제가 생기면 위치를 특정할 수 있고, 역추적 불가능한 숫자는 통째로 다시 만드는 수밖에 없다.
- 평가에서 숫자 정확률을 텍스트 품질에서 떼어내 단독 집계할 것 — 가장 놓치기 쉬운 항목이다. 총점 하나에 섞으면 유창함이 사실 오류를 덮어버리고, 단독으로 분리해야 「조작률」이 낮출 수 있는 KPI가 된다.
- 검증 폐루프 = 회귀셋(상용 전) + Trace 모니터링(상용 중) + Bad Case 환류(상용 후) — 이 세 구간을 합쳐야 「구현 가능」이며, 어느 하나가 빠지면 개념적 답변이다. 이 구간을 능동적으로 보충할 수 있으면 「어떻게 하는지 안다」에서 「해봤다」로 올라간다.
엔지니어링 실전 Tips
- 지표마다 「기준 카드」를 만들 것: 필드명, 시간 범위 정의, 중복 제거 규칙, 테스트 계정 포함 여부, 계산식. 기준이 없는 지표는 일률적으로 주보에 올리지 않는다.
- 항등식을 사람의 눈이 아니라 어서션으로 만들 것: 총계 = 항목의 합, 주기 완전성, 전기 대비 분모가 0이 아님 — 이런 검사를 계산층에 써넣고 실패하면 발행을 차단할 것.
- 강등 전략을 미리 설계할 것: 데이터가 결손일 때의 올바른 행위는 「결손 표기 / 되묻기」이지 모델이 그럴듯해 보이는 숫자를 스스로 채우는 것이 아니다. 시스템에는 「이 부분은 데이터가 없음」이라는 합법적 출력 형태가 있어야 한다.
- Structured Outputs + Function Calling은 선택이 아니라 표준 장비다: 이것들이 「모델의 자유 발휘」를 「모델이 구조를 채우기 / 도구를 호출하기」로 수렴시키며, 3층 아키텍처가 API 계층에 착지하는 지점이다.
- 숫자 정확률, 기준 일관성, 조작률 세 지표를 독립적으로 채점할 것: 「주보 품질 점수」 하나로 합성하지 말 것. 그러면 문체가 좋을 때 숫자 오류가 점수에 묻혀 올라간다.
- Trace로 숫자를 역조회할 수 있어야 한다: 상용 후 「각 숫자가 어느 쿼리에서 왔는지」를 기록해, 사용자가 기준을 되물으면 그 자리에서 설명할 수 있어야 한다. 이것이 기업 리포트가 사용 가능해지는 문턱이다.
- 답변 순서 제안: 먼저 귀인을 교정(환각이 아니라 사실 사슬을 묻는 것) → 3층 아키텍처 → 3단 워크플로 → 평가 지표 → 검증 폐루프를 능동적으로 보충.