정말로 작동하는 문서 Q&A: 패턴과 함정

"내 문서에 질문을 던져보자"는 비즈니스 AI라는 발상 전체를 팔리게 만드는 사용 사례입니다. 모델을 당신의 계약서, 정책, 매뉴얼에 겨누면, 평이한 언어로 답합니다. 데모는 자석처럼 끌어당기고, 첫 버전은 만들기가 정말로 쉽습니다. 문제는 그 쉬운 버전이 당신이 시도해 본 질문에서는 작동하고 사용자가 실제로 던지는 질문에서는 실패한다는 점입니다. 이 글은 그 차이에 관한 것입니다. 문서 Q&A를 신뢰할 만하게 만드는 패턴들과, 작동하는 것처럼 보이게 하면서 조용히 틀리게 만드는 함정들 말입니다.

대부분의 실패는 검색의 실패다

중요한 멘탈 모델은 이것입니다. 문서 Q&A는 하나가 아니라 두 개의 시스템입니다. 먼저, 검색이 답을 담고 있을 법한 구절들을 찾습니다. 다음으로, 모델이 그 구절들을 읽고 응답을 작성합니다. 거의 모두가 두 번째 부분에 집착하지만, 실제로는 첫 번째 부분에서 일이 무너집니다. 관련 구절이 애초에 모델 앞에 놓이지 않는다면, 아무리 유창하게 생성해도 올바른 답을 되찾을 수 없습니다. 모델은 매끄럽게, 그리고 틀리게 즉흥 연주를 할 것입니다. 나쁜 답변을 두고 모델을 탓하기 전에, 올바른 텍스트가 검색되기는 했는지부터 확인하십시오. 대개는 검색되지 않았습니다.

청킹이 무엇을 찾을 수 있는지를 결정한다

질문마다 전체 문서 라이브러리를 모델에 통째로 넣을 수는 없으므로, 문서는 청크로 쪼개지고, 검색이 뒤지는 것은 바로 그 청크들입니다. 따라서 어떻게 쪼개느냐는 조용하지만 결정적인 설계 선택입니다. 너무 작게 쪼개면 하나의 답이 여러 조각으로 잘려 흩어져, 어떤 청크 하나도 충분하지 않게 됩니다. 너무 크게 쪼개면 각 조각이 자기 관련성을 희석해, 핵심 문장이 검색 점수가 낮은 잡음 속에 파묻힙니다. 더 나쁜 경우, 단순한 분할은 표를 반으로 자르거나, 제목을 그 절에서 떼어 놓거나, 조항을 그것을 규율하는 조건에서 떼어냅니다. 좋은 청킹은 N글자마다 잘라내고 잘되기를 바라는 대신, 문서의 구조 — 절, 제목, 목록 항목 — 를 존중합니다.

키워드와 의미 모두 중요하다

초기 시스템은 임베딩을 써서 질문과 의미적으로 유사한 구절을 찾으며, 의미만으로 매칭했습니다. 이것은 강력하지만 맹점이 있습니다. 바로 정확한 용어입니다. 특정 부품 번호, 오류 코드, 조항 참조, 혹은 고유명사를 찾는 사용자는 정확한 매칭이 필요한데, 순수한 의미 검색은 "같은 주제에 관한" 구절로 표류하면서 문자 그대로의 문자열을 놓칠 수 있습니다. 견고한 패턴은 접근법을 결합하는 것입니다. 의미를 위한 의미 검색과, 정밀함을 위한 키워드 검색을 함께 써서, "재택근무에 관한 우리 정책은 무엇인가"와 "4.2(b)항" 둘 다 올바른 구절에 안착하게 하는 것입니다. 임베딩과 검색을 위한 도구는 Hugging Face 문서 같은 자료에 잘 정리되어 있습니다. 설계 판단은 당신의 몫입니다.

"문서에서만 답하라"는 지시

올바른 구절들이 검색되고 나면, 생성 단계에는 무엇보다 중요한 한 가지 임무가 있습니다. 검색된 텍스트에서, 오직 검색된 텍스트에서만 답하는 것입니다. 모델은 방대한 세계 지식을 지니고 있어서, 제약하지 않으면 당신의 문서가 말하는 것과 자신이 일반적으로 믿는 것을 섞어버립니다. 회사가 작성한 적 없는 정책을 Q&A 시스템이 확신에 차서 단언하게 되는 경로가 바로 이것입니다. 모델에게 제공된 구절에 답을 근거하고, 출처를 인용하거나 표기하며, 구절에 답이 없으면 분명히 그렇게 말하도록 명시적으로 지시하십시오. 그 마지막 행동 — "문서에는 이에 대한 내용이 없습니다" — 은 기능입니다. 늘 답하는 시스템은 가끔 거짓말하는 시스템입니다.

인용은 선택 사항이 아니다

출처 표기 없는 문서 Q&A 답변은 추측보다 나을 게 거의 없습니다. 사용자가 검증할 방법이 없기 때문입니다. 신뢰를 쌓는 패턴은 답변을 그것이 나온 특정 구절과 함께 반환해, 사람이 클릭해 들어가 확인할 수 있게 하는 것입니다. 이것은 세 가지 일을 합니다. 사용자가 검색 오류를 스스로 잡게 하고, 시스템을 감사 가능하게 만들며, 이제 증거를 가리켜야 하므로 모델의 행동을 근거 있는 답변 쪽으로 옮깁니다. 결과가 중대한 무엇 — 법률, 의료, 금융, 컴플라이언스 — 에 대해서는 인용이 친절이 아닙니다. 그것은 사람이 결정에 대한 책임을 유지하는 메커니즘이며, 결과가 실재할 때 NIST AI 위험 관리 프레임워크 같은 체계가 기대하는 바로 그런 통제입니다.

시스템을 무너뜨리는 질문들

잘 만들어진 시스템조차 대비할 만한 예측 가능한 실패 양상이 있습니다. 여러 문서를 종합해야 하는 질문("이 정책이 수년간 어떻게 바뀌었는가")은 단순 검색을 압박합니다. 검색은 몇 개의 관련 구절을 찾도록 조정되어 있지, 그것들을 전부 집계하도록 되어 있지 않기 때문입니다. 문서가 말하지 않는 것에 의존하는 질문은 거의 불가능합니다. 검색은 부재를 떠올릴 수 없기 때문입니다. 비교와 집계 질문("어느 계약이 X를 언급하는가")은 구절 검색과는 다른 접근이 필요합니다. 그리고 표, 도표, 스캔 이미지는 종종 진짜 답을 담고 있으면서도 텍스트 기반 검색에는 보이지 않습니다. 이 한계들을 아는 것이, 구조적으로 줄 수 없는 답을 약속하는 대신 시스템의 범위를 정직하게 정하게 해줍니다.

검색과 답변을 따로 측정하라

마지막 패턴은 팀들이 건너뛰었다가 후회하는 것입니다. 정답과 출처 구절을 알고 있는 실제 질문 모음을 만들고, 두 가지를 독립적으로 측정하십시오. 검색이 올바른 구절을 떠올렸는가, 그리고 그것이 주어졌을 때 모델이 올바르게 답했는가. 이 둘을 하나의 "답이 좋은가" 점수로 뭉뚱그리면 시스템이 어디서 실패하는지가 가려져, 눈먼 채로 튜닝하게 됩니다. 둘을 분리하면 진단이 즉각적입니다. 검색 누락과 생성 누락은 완전히 다른 해결책을 요구하기 때문입니다. 청킹, 검색, 혹은 프롬프트를 바꿀 때마다 이 평가를 다시 돌리십시오. 그 변경 하나하나가 예전에 잘되던 질문을 조용히 망가뜨릴 수 있기 때문입니다.

지식을 신선하게 유지하고 사용자의 질문을 살펴라

문서 Q&A 시스템이 출시 후에도 좋은 상태를 유지하는지를 결정하는 두 가지 운영 현실이 있으며, 둘 다 구축 단계의 일부가 아니어서 소홀히 하기 쉽습니다. 첫째는 신선도입니다. 바탕 문서가 바뀌는 순간 — 정책이 개정되고, 매뉴얼이 갱신되고, 계약이 대체되는 순간 — 당신의 색인은 낡고, 낡은 색인은 확신에 차서 구식인 답변을 만들어냅니다. 바뀐 문서를 다시 수집하고 폐기된 문서를 제거하는 프로세스가 필요합니다. 시스템은 자신이 검색해 온 구절이 지난 분기에 대체된 규칙을 설명하고 있다는 사실을 알 길이 없기 때문입니다. 출시 시점에는 옳았지만 오늘은 틀린 답변은 가장 해로운 실패 중 하나입니다. 한때 작동했기에 모두가 확인을 멈췄다는 바로 그 이유 때문입니다.

두 번째 현실은 사용자가 당신이 전혀 예상하지 못한 것을 물으리라는 것이며, 실제 질문 로그는 시스템이 만들어내는 가장 가치 있는 산물입니다. 그것을 읽으십시오. 나쁜 답변을 받는 질문들은 검색이 어디서 실패하는지, 문서에 어디에 구멍이 있는지, 사용자가 시스템이 구조적으로 제공할 수 없는 어떤 기능을 기대하는지를 정확히 알려줍니다. "AI가 틀렸다"는 많은 불만은 알고 보면 "문서가 이걸 다룬 적이 없다"로 밝혀집니다. 그것은 모델 문제가 아니라 콘텐츠 문제이며, 오직 질문 로그만이 드러낼 수 있는 것입니다. 돌아가는 시스템을 당신의 문서가 무엇을 놓치고 있는지 발견하는 도구로 다루십시오. 그러면 Q&A 계층은 단지 구멍을 덮어 가리는 대신, 바탕 지식 베이스를 개선합니다.

정리

문서 Q&A는 마법의 답변 상자가 아니라, 위에 생성 단계가 얹힌 검색 문제로 다룰 때 작동합니다. 청킹할 때 문서 구조를 존중하고, 의미 검색과 키워드 검색을 결합하며, 답변을 검색된 텍스트에 근거하도록 강제하고, 인용을 반환하며, 검색과 생성을 별개의 것으로 측정하십시오. 무엇보다도, 무너지지 않는 질문만 데모하는 대신 시스템을 무너뜨리는 질문을 대비해 설계하십시오. 그렇게 하면 문서에 질문을 던지는 일은 더 이상 묘기가 아니라, 신뢰할 수 있는 도구가 됩니다.