대부분의 RAG 튜토리얼은 검색 품질에 초점을 맞춥니다. 즉, 더 나은 임베딩(embeddings), 더 나은 청킹(chunking), 더 나은 재순위화(reranking)입니다. 하지만 이들이 간과하는 부분은 사용자가 출력을 신뢰할 수 있을지 여부를 결정하는 부분, 즉 검색된 컨텍스트가 실제로 질문에 답하지 못했을 때 무슨 일이 벌어지는지에 대한 것입니다.

제가 WhatsApp을 통해 제공하고 PostgreSQL의 pgvector를 이용한 벡터 검색으로 백업한 RAG 어시스턴트를 구축했을 때, 검색 파이프라인은 쉬운 부분이었습니다. 어려운 부분은 제가 '신뢰도 문제(confidence problem)'라고 부르는 것이었습니다. LLM은 검색된 컨텍스트가 빈약하거나 누락되었을 때조차 확신에 찬 것처럼 들립니다. 데모는 그것을 허용합니다. 하지만 실제 사용자의 질문에 답하는 프로덕션 어시스턴트는 그렇지 않습니다.

해결책은 프롬프트 기반이 아닌 구조적인 것이었습니다. 모델에게 '제공된 컨텍스트만을 기반으로 답변하라'고 요청하는 대신, 모든 주장이 특정 검색 청크를 가리키는 인용(citation)을 포함해야 하는 구조화된 JSON 출력을 강제했습니다. 만약 모델이 그 필드를 채울 수 없다면, 사용자에게 도달하기 전에 응답이 거부되었고, 시스템은 '답변할 충분한 정보가 없습니다'로 폴백(fallback)되었습니다.

이는 전체 설계 논의를 검색 재현율(retrieval recall) 최적화에서, 검색된 내용과 모델이 주장하도록 허용되는 내용 사이의 격차를 메우는 것으로 전환시킵니다:

• 모호한 청크가 인용할 수 없는 주장을 생성하기 때문에 청킹이 더 보수적으로 바뀌었습니다.

• 강제가 지침(instructions)에서 스키마 검증(schema validation)으로 이동했기 때문에 시스템 프롬프트는 더 짧아졌습니다.

• 실패가 조용하게 발생하는 것이 아니라 눈에 보이게 되었습니다. 나쁜 검색은 이제 자신감 넘치는 오답이 아니라 '모릅니다'를 생성합니다.
  검색 품질은 데모를 가져다줍니다. 인용 강제는 돌보지 않아도 되는 실제 사용자 앞에 내놓을 수 있는 무언가를 가져다줍니다.