오답 60건을 시스템 시점에서 감사하기: 실패를 근거 활용과 후보 회수로 나누고 개선안을 실측으로 거른 기록

캐피탈 사내 규정 165문항 평가에서 XGEN의 GraphRAG 검색 구성은 런마다 76.4%에서 85.5% 사이에 머물렀습니다. 환경 2개, 답변 모델 2개, 임베딩 2개를 조합한 런 4개의 오답을 교차해 보니 17문항은 네 런 모두에서 틀렸습니다. 모델, 임베딩, 환경과 무관하게 틀리는 문항이라면 파라미터를 하나씩 바꾸는 튜닝으로는 풀리지 않는다고 판단했습니다.

그래서 오답 전체를 하나의 원인 체계로 분해하기로 했습니다. 핵심 질문은 "정답이 검색되지 않았는가, 검색됐는데 답변이 쓰지 못했는가"였습니다. 이 둘은 고칠 자리가 완전히 다릅니다. 앞쪽은 검색 엔진과 그래프 빌드를, 뒤쪽은 근거를 구성하는 방식과 답변 프롬프트를 고쳐야 합니다.

이 글은 그 분해를 어떤 방법으로 했는지, 무엇이 드러났는지, 그 결과로 세운 개선안이 실측에서 어떻게 걸러졌는지를 다룹니다. 결론부터 말하면 오답의 60%는 검색이 아니라 근거 활용에서 났고, 검색 쪽 개선안은 대부분 실측에서 기각됐습니다.

평가 점수가 말해 주지 않는 것

평가셋은 고객이 만든 165문항으로, 단일 조회, 관계형, 교차 문서가 55문항씩입니다. 기대답변은 질문이 가리키는 규정의 정의 조항 원문 발췌입니다. 교차 문서 문항은 정답 규정이 2~3개입니다.

단일 조회는 네 런 모두 55/55였고, 오답은 교차 문서와 관계형 일부에 몰려 있었습니다. 네 런 공통 오답 17문항 중 16문항이 교차 문서였습니다. 근거 5개 고정 구성은 자동 구성보다 개발 환경에서 10건, 체험 환경에서 7건 더 틀렸는데, 늘어난 오답은 전부 "근거 5개 안에 두 번째 규정이 없음"이었습니다.

검색 파이프라인은 다음과 같습니다. 질문 하나가 LLM 질의 분할을 거쳐 여러 질의로 나뉘고, 질의마다 후보 풀을 만든 뒤 융합 점수로 근거를 고릅니다.

질문 → LLM 질의 분할(2~4개, 병렬)
  ① 벡터 후보      ANN 상위 100 → 최고점 60% 미만 절단        → ≤40
  ①-2 낱말 보강    질문 낱말 포함 청크 → 질문 벡터 상위         → ≤12
  ② 파일 보정      후보에 없는 파일에서 질문 벡터 상위          → ≤12
  ③ 그래프 확장    라벨 링킹 시드 → 이웃 → 개체의 청크 → 질문 벡터 상위 → ≤12
후보 풀 상한 76(통상 64)
  ④ 융합 순위      밀집 1.0 + BM25(풀 안) 0.8 + PPR 0.15 → 절단 → MMR → 근거 8~16

점수만 보면 무엇이 문제인지 알 수 없습니다. 정답 규정이 후보 풀에 들지 못한 것인지, 풀에는 들었는데 융합에서 잘렸는지, 근거까지 갔는데 답변이 놓쳤는지는 단계별로 직접 대조해야 했습니다.

시스템이 보는 정보만으로 정답 청크를 추적하기

감사 원칙은 하나였습니다. 골든셋의 정답 앵커는 쓰지 않는다. 앵커를 쓰면 "정답을 아는 상태"의 진단이 되고, 그 진단으로 만든 개선은 골든셋을 외우는 방향으로 흐르기 쉽습니다. 그래서 시스템이 실제로 보는 것(질문, 분할 질의, 근거, 청크)만으로 판정했습니다.

정답 청크는 정답 규정 파일의 청크 중 기대답변과 3-gram 겹침이 가장 큰 청크로 정의했습니다. 개발 환경 자동 구성의 오답 29문항을 하나씩 워크플로우로 다시 실행해 분할 질의, 근거, 인용, 답변을 받았고, 분할 질의별 근거와 벡터 순위(상위 300), 같은 컬렉션 약 1.5만 청크로 만든 본문 BM25 순위, 정답 청크에 연결된 그래프 노드 중 질문에 글자 그대로 나오는 라벨을 대조했습니다. 파일명은 확장자를 떼고 대조했습니다. 우회 적재한 문서의 확장자가 골든셋 표기와 달라 정확 일치로 세면 정답 규정 일부가 구조적으로 누락 처리되는 결함이 직전에 드러났기 때문입니다.

검색 쪽 실패 24건만 따로 보면 패턴이 분명했습니다. 본문 BM25로는 분할 질의 최고 순위 24위 안에 18건, 40위 안에 19건이 있었지만 벡터로는 40위 안이 7건뿐이었습니다. 어휘로도 닿지 않는 것은 기대답변 표현이 청크와 다른 1건뿐이었습니다. 컬렉션 전체 기준으로도 교차 문서 정답 규정 125건 중 본문 BM25 상위 40은 119건, 벡터 단독 상위 40은 101건을 회수했습니다. 이 골든셋에서는 어휘 채널이 벡터와 대등 이상이었습니다.

근거가 있는데 왜 답이 틀렸나

36건이 이번 감사의 중심이었습니다. 정답 청크가 근거에 있는데 답변이 쓰지 못했다면, 에이전트가 실제로 받은 입력을 봐야 했습니다. 워크플로우 노드와 같은 규칙(질의별 근거 라운드 로빈 병합, 중복 제거, 따옴표 구 우선 정렬, 8만 자 절단)으로 에이전트가 받은 근거 블록을 재구성했습니다.

결과는 예상과 달랐습니다. 근거에 있던 정답 청크 36개 중 19개가 첫 번째 근거 문서였고, 두 번째 근거 문서까지 넓히면 24개였습니다. 절단으로 정의가 잘린 것은 1개뿐이었습니다. 정의 조문은 근거의 맨 앞에 온전히 있었는데, 답변이 그 청크를 인용한 것은 36개 중 12개였습니다. 문항별로 원문을 대조해 네 가지 기제를 확인했습니다.

확인 방법은 같은 검색 결과에서 답변 프롬프트만 바꾸는 대조 실험이었습니다. 고객 원본 프롬프트의 29문항 겹침 중앙값은 0.24였고, 정의 문장 원문 인용과 지정 규정 범위 제한을 넣으면 0.25로 중앙값은 거의 그대로였지만 0.5 이상인 문항이 1개에서 4개로 늘었습니다. 정의 조항을 각 호까지 원문 인용하게 한 10문항 실험에서는 대표 문항의 겹침이 0.19에서 0.95로 올랐습니다. 반대로 법령 선택이나 두 번째 규정 누락이 겹친 문항은 프롬프트로 바뀌지 않았습니다. 프롬프트로 고쳐지는 문항과 고쳐지지 않는 문항이 원인 분해와 정확히 일치했다는 점이 분해가 맞았다는 근거가 됐습니다.

여기서 나온 가장 중요한 발견은 기술 결함이 아니었습니다. 고객의 시스템 프롬프트와 골든셋이 서로 반대 방향을 가리키고 있었습니다. 프롬프트는 요약, 500토큰, 법령 우선을 지시하고, 골든셋의 기대답변은 내규·자율규제 정의 조항의 원문 발췌입니다. 같은 프롬프트를 쓴 경쟁 에이전트의 66.7%도 같은 벽에 부딪힌 결과로 해석했습니다. 이 차이는 코드로 해결할 문제가 아니라 고객과 합의해야 할 문제로 분리했습니다.

원인 9가지와 개선안, 그리고 지키기로 한 원칙

검색 쪽 원인도 세분했습니다. 질문이 이름으로 부른 규정이 질문 벡터를 지배해, 같은 용어를 정의한 두 번째 규정은 벡터 100위 밖으로 밀렸습니다(교차 문서 누락 25건 중 18건). 그래프에는 앵커 용어가 개체 노드로 있고 정답 청크에 직접 연결돼 있는데, 그래프 확장이 최대 500개 풀을 질문 벡터로 12개만 다시 고르는 단계에서 탈락한 경우가 13건이었습니다. 정의 용어 자체가 노드로 추출되지 않은 경우가 8건이었습니다.

개선안 F1~F10에는 변경 위치, 로직, 근거, 기대 효과, 리스크, 검증 방법을 적었습니다. 원칙도 함께 정했습니다. 도메인 단어 목록, 예시 문자열, 환경별 상수는 쓰지 않고, 모든 상한은 기존 파라미터 체계 안에서 데이터 통계로 정합니다.

측정 프로토콜도 고정했습니다. 골든셋, judge, 답변 모델을 고정하고, 변경 한 건마다 검색 회수를 먼저 잽니다. 검색 회수가 오르지 않는 변경은 평가 런을 돌리지 않습니다. 정확도는 답변 모델과 judge의 회차 변동이 섞여 작은 효과를 가리기 때문입니다. 산식으로 보면 근거 활용 36건은 답변 쪽 개선으로, 검색 쪽 24건 중 18~19건은 검색 개선으로 닿을 수 있고, 골든셋 형식 문제 2~3건은 코드 밖이라 코드로 도달 가능한 상한은 약 160~162/165로 추정했습니다.

개선안을 실측으로 거르자 남은 것

검색 쪽 개선안은 체험 환경 컨테이너에 원복을 전제로 한 핫패치를 넣어 먼저 쟀습니다.

어휘 채널은 회수를 올렸지만 회귀를 만들었습니다. 컬렉션 전체 청크로 BM25 색인을 만들어 후보 채널로 넣고 융합의 어휘 점수도 코퍼스 BM25로 바꾸자, 원복 후 다시 잰 원본 기준 교차 문서 정답 전부 회수가 31에서 39/55로, 정답 규정 회수가 100에서 108/125로 올랐습니다. 단일 조회와 관계형은 55/55 그대로였습니다. 흥미롭게도 새로 회수된 23청크 중 20개는 벡터 검색 출처였습니다. 효과의 대부분은 후보 추가가 아니라 IDF를 풀 안 40여 청크가 아닌 컬렉션 전체에서 계산한 융합 점수에서 나왔습니다. 165문항 평가 런도 85.5%에서 87.3%로 올랐습니다. 그런데 50문항 세트에서 한 문항이 네 구성 중 세 구성에서 새로 틀렸습니다. 원인을 추적하니 융합 어휘 점수를 파일명 가중이 있는 라이브러리 BM25F에서 파일명 가중이 없는 코퍼스 BM25로 바꾼 것이 문제였습니다. 법령 이름을 본문에 반복 인용하는 짧은 개정문·부칙 청크가 이겨 정답인 제1조 청크를 밀어냈습니다. 융합은 라이브러리 방식으로 두고 후보 채널로만 쓰는 판으로 고치자 그 문항은 근거에 복귀했지만, 답변 수준에서는 오히려 원본보다 낮았습니다(50문항 중 38 대 41). 결국 어휘 색인은 문서 적재와 삭제 경로까지 건드려야 하는 변경이라 제품 반영을 보류했습니다.

그래프 시드 보장은 최종 근거에 닿지 않았습니다. 교차 문서 정답 125건 중 시드 보장으로 들어온 58건 중 56건은 벡터와 어휘가 이미 찾은 청크였습니다. 그래프 확장으로 들어온 청크는 융합 절단을 거의 넘지 못했습니다(1,980건 중 기준 79건, 패치 후 6건). 파일당 보장으로 바꾸면 정답이 2건 늘었지만 근거 중앙값이 11개에서 19개로 늘어, 근거 과다(R6)를 악화시키는 대가가 커서 채택하지 않았습니다. 그래프 점수를 순위에 직접 쓰는 그래프 우선 순위도 실측했는데, 교차 문서 정답 전부 회수가 31에서 25로 줄어 기각했습니다. 시드가 '정리', '개인' 같은 낱말 조각으로 잡혔고, 상위 5개는 문항과 무관하게 개체가 많은 법령 청크(허브)가 차지했습니다. 구조적으로도 용어 노드는 정의 청크와 그 용어를 인용만 한 청크에 같은 언급 간선으로 연결돼 있어, 인접성만으로는 둘을 가를 수 없었습니다.

수치가 좋아도 원칙에 어긋나면 채택하지 않았습니다. 정의 문형("X란 ... 말한다")을 규칙으로 추출해 정의 노드를 만들고 그래프 채널을 융합에 넣은 로컬 실험은 165문항 교차 문서 회수를 31에서 43/55로 올렸고, 조문 단위 청킹 실험도 비슷한 수준을 보였습니다. 하지만 둘 다 문서 형식의 문법을 별도 규칙으로 뽑는 방식이라 앞서 정한 원칙의 하드코딩에 해당한다고 판단해 실측 기록만 남기고 기각했습니다.

회고와 남은 과제

이번 감사에서 가장 쓸모 있었던 것은 "검색 누락"이라는 한 단어를 후보 미회수, 같은 규정의 다른 청크, 근거 있음·답변 실패로 쪼갠 것이었습니다. 정확도 점수만 봤다면 검색 튜닝에 시간을 썼을 텐데, 실제로는 오답의 60%가 이미 근거에 있는 정답을 답변이 쓰지 못한 경우였습니다. 그리고 그중 상당 부분은 고객 프롬프트와 골든셋의 방향 차이라는, 코드 밖의 문제였습니다.

두 번째로 배운 것은 기획과 검증을 분리하는 것입니다. 기획 단계에서 근거를 갖춰 세운 개선안도 실측에서는 회귀를 만들거나 효과가 없었습니다. 검색 회수를 먼저 재고 오르지 않으면 평가를 돌리지 않는 프로토콜이 있었기에 기각 판단을 빠르게 내릴 수 있었습니다. 어휘 채널의 회귀처럼 집계 수치는 오르는데 개별 문항이 무너지는 경우는 문항 단위 전이(얻은 문항, 잃은 문항)를 같이 봐야 보였습니다.

남은 과제는 세 가지입니다. 기대답변 범위와 채점 기준, 답변 프롬프트의 방향은 고객과 합의가 필요한 항목으로 남겼습니다. 답변 모델, 질의 분할, judge가 모두 온도 1이라 같은 설정의 회차 폭이 약 5%p여서, 작은 개선을 재려면 측정용 온도 0 사본이 먼저 필요합니다. 마지막으로 그래프 채널이 벡터 점수에 묶이지 않고 독립적으로 살아남는 구조, 그리고 관계의 원문 근거를 검증한 빌드가 그래프 쪽 효과를 다시 따져 볼 전제 조건입니다.