왜 근거 기반 답변이 필요한가 — 찾은 것을 그냥 붙이면 안 되는 이유

한 줄 요약

13장에서는 고객의 질문과 관련된 청크를 검색했습니다. 이번 장에서는 모델이 검색한 내용을 근거로 답변을 작성하도록 합니다. 고객지원에서는 자연스러운 답변만큼이나 정확한 근거가 중요합니다. 검색한 내용에서 확인되는 사실만 안내하고, 출처를 명시하며, 확인할 수 없는 내용은 그 한계를 밝히도록 구현합니다.

1. 13장까지 된 것, 아직 안 된 것

된 것	안 된 것
정책 청크 12개가 `chroma_db/`에 저장되어 있다	찾은 청크로 답을 쓰는 일
질문을 넣으면 가까운 청크가 나온다	그 답이 어디서 나왔는지 밝히는 일
	찾은 청크에 답이 없을 때 어떻게 할지

13장의 마지막에 남긴 문장이 있습니다. "찾아 준 것이 정말 답인지는 아직 아무도 확인하지 않았습니다." 검색은 관련이 없어도 항상 k개를 돌려주기 때문입니다.

2. RAG의 세 단계

12장에서 본 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 의 세 단계 가운데, 이번 장에서는 나머지 두 단계를 만듭니다.

단계	하는 일	누가 하나	어느 장
검색(Retrieval)	질문과 가까운 청크를 찾는다	임베딩 모델 + Chroma	13장
증강(Augmented)	찾은 청크를 프롬프트에 넣는다	우리 코드	이번 장
생성(Generation)	그 프롬프트로 답을 쓴다	LLM	이번 장

"증강"은 어려운 말처럼 들리지만 하는 일은 단순합니다. 질문 앞에 참고 자료를 붙여 주는 것입니다.

3. 그냥 붙이기만 하면 생기는 세 가지 문제

찾은 청크를 질문과 함께 넣으면 그럴듯한 답이 나옵니다. 그런데 그대로 고객에게 내보내기에는 세 가지가 걸립니다.

첫째, 모델이 발췌 밖의 지식을 섞습니다. 모델은 세상의 수많은 쇼핑몰 정책을 읽고 학습했습니다. 발췌에 빈 곳이 있으면 그 일반 지식으로 메웁니다. 3장에서 환불액을 계산하게 했을 때, 모델이 문제에 없는 규칙을 스스로 채워 넣어 금액이 달라진 것을 봤습니다. 같은 일이 여기서도 일어납니다.

둘째, 답이 어디서 나왔는지 알 수 없습니다. "편도 3,000원입니다"라는 답이 정책 문서에서 온 것인지 모델의 짐작인지 답만 봐서는 구별되지 않습니다. 고객도, 답을 검토하는 상담원도 확인할 방법이 없습니다.

셋째, 답이 없는 질문에도 답합니다. 정책 문서에 없는 내용을 물어도 검색은 청크 네 개를 돌려주고, 모델은 그 청크에서 뭔가를 엮어 답을 만들어 낼 수 있습니다. 1장에서 본 환각(hallucination) 입니다.

4. 그래서 세 가지를 요구한다

요구	막는 것	이번 장에서 만드는 장치
발췌 안에서만 답한다	일반 지식이 섞이는 것	시스템 프롬프트의 첫 문장
출처를 밝힌다	확인할 수 없는 답	발췌마다 붙이는 출처 꼬리표 + 표기 규칙
없으면 없다고 한다	환각	정해진 기권 문구

모델의 답을 주어진 근거 자료에 묶어 두는 것을 그라운딩(grounding) 이라고 부릅니다. 이번 장의 제목인 "근거 기반 답변"이 이것입니다.

5. 이걸 모르면 무엇을 판단하지 못하는가

답이 틀렸을 때 검색이 못 찾은 것인지, 모델이 발췌를 잘못 읽은 것인지, 발췌 밖에서 지어낸 것인지 가리지 못합니다.
답에 붙은 출처가 맞는 출처인지 확인하는 방법을 알지 못합니다.
"모른다"고 답한 것이 잘한 것인지 못한 것인지 판단하지 못합니다. 문서에 없는 질문에 모른다고 한 것은 잘한 것이고, 문서에 있는데 모른다고 한 것은 검색이 못 찾은 것입니다.

핵심 정리

13장은 찾기까지 했습니다. 이번 장은 찾은 것으로 답하기를 합니다.
RAG는 검색 → 증강 → 생성 세 단계입니다. 증강은 우리 코드가, 생성은 LLM이 합니다.
찾은 청크를 그냥 붙이면 일반 지식이 섞이고, 출처를 알 수 없고, 없는 답을 지어냅니다.
그래서 발췌 한정, 출처 표기, 기권 세 가지를 요구합니다.