98 대 86으로 진 평가는 같은 조건의 비교가 아니었습니다

캐피탈 고객이 직접 수행한 50문항 평가에서 경쟁 클라우드 에이전트는 98%, 저희 구성은 86%였습니다. 실행 기록을 열어 보니 채점 기준과 문서 적재 상태가 비교할 수 있는 상태가 아니었습니다. 165문항으로 비교를 다시 설계하면서 무엇을 왜 고정했는지, 그리고 그 조건에서 한 번 실행한 결과가 무엇을 말하고 무엇을 말하지 않는지 정리합니다.

---

출발점은 고객 평가에서 진 숫자였습니다

고객은 사내 규정을 묻는 50문항으로 두 에이전트를 평가했고, 경쟁 에이전트 98% 대 저희 벡터 검색 구성 86%가 나왔습니다. 이 숫자를 받아들이기 전에 실행 기록부터 확인했습니다.

두 가지가 걸렸습니다. 채점이 정확도가 아니라 안전성 기준으로 수행됐고, 저희 쪽 컬렉션에서는 자율규제 문서 67건 중 66건이 Word 파싱에 실패해 오류 문자열 한 줄로만 적재돼 있었습니다. 경쟁 에이전트의 인덱스에는 같은 문서의 본문이 있었습니다.

비교에는 고객이 만든 165문항을 쓰기로 했습니다. 단일 조회, 관계형, 교차 문서가 55문항씩이고 문항마다 정답 문서가 지정돼 있습니다. 그중 47문항의 정답 문서가 파싱에 실패한 66건에 들어 있었습니다. 그대로 실행하면 검색 로직과 무관하게 47문항은 저희가 답할 수 없는 상태였습니다.

점수 차이가 검색과 답변 구성에서만 나오게 했습니다

조건을 고르는 기준은 하나였습니다. 두 에이전트의 점수 차이가 검색과 답변 구성의 차이에서만 나와야 한다. 그 밖의 차이는 하나씩 없앴습니다.

채점 모델은 답변 모델과 다른 계열로 골랐습니다. 답을 만든 모델이 자기 답을 채점하는 구성은 피하고 싶었습니다.

조건을 맞추는 쪽이 저희에게 불리한 항목도 있었습니다. 기존 컬렉션 조건(약 1,000자 청크, 더 큰 임베딩 모델)을 경쟁 쪽 조건으로 바꾸자, 자체 채점(0~5점)에서 적재가 정상인 118문항 평균이 4.45에서 4.27로 내려갔습니다. 그래도 비교는 맞춘 조건으로 했습니다.

맞췄다고 생각한 조건이 틀린 경우도 있었습니다

청크 설정이 같다고 청크가 같지는 않았습니다. 실제로 측정해 보니 마크다운 문서는 중앙값 1,964자로 설정에 맞았지만, Word 문서는 서버 파서가 표와 별표를 분할하지 않아 2,000자를 넘는 청크가 35%였습니다. 바이트 단위로 같은 청크가 아니라는 점을 결과 보고에 조건으로 적었습니다.

근거 개수는 더 큰 교훈이었습니다. 앞선 회차들은 전달받은 설정 자료를 믿고 경쟁 쪽이 상위 3개를 쓴다고 보고 맞췄습니다. 나중에 경쟁 에이전트의 실제 정의를 읽기 전용으로 조회해 보니 이 문서셋 쪽은 처음부터 상위 5개였고, 3개는 다른 에이전트의 값이었습니다. 이전 회차의 같은 조건은 실제로는 3 대 5였습니다. 이 글의 결과 회차는 5 대 5로 실행했고, 그 설정이 맞았다는 것은 이 조회로 뒤늦게 확인했습니다. 같은 조회로 경쟁 쪽이 질의 시점에 키워드 검색만 쓴다는 것도 확인했습니다. 맞춰 둔 임베딩 모델은 질의 때 쓰이지 않는 항목이었던 셈입니다.

상대의 설정은 전달받은 문서가 아니라 실제 정의에서 확인해야 했습니다.

대조군도 의심해야 했습니다. 이 플랫폼은 그래프가 있는 컬렉션에서 일반 검색 설정을 자동으로 그래프 검색으로 바꿔, 처음 만든 벡터 검색 대조군은 사실 대조군이 아니었습니다. 자동 전환이 없는 경로를 찾아 대조군을 다시 만들었습니다.

근거 개수를 숫자로 맞추는 것도 완전한 같은 조건은 아닙니다. 청크와 검색 방식이 다르면 같은 5개에 담기는 내용이 다릅니다. 그래서 상위 5개 고정 구성과, 엔진이 질문마다 근거 수를 정하는 구성을 함께 실행했습니다.

평가기가 저희 쪽 시간을 부풀리고 있었습니다

응답 시간에도 이상한 점이 있었습니다. 평가기가 기록한 저희 구성의 문항당 시간 중앙값은 54초였는데, 서버 로그로 본 실행은 질의 분할 약 1초, 검색 78초, 답변 35초를 합쳐 11~14초였습니다.

원인은 평가기 안에 있었습니다. 비동기로 실행되는 평가 작업이 채점 모델을 동기 HTTP로 호출해, 채점에 걸리는 5~40초 동안 프로세스의 이벤트 루프가 멈췄습니다. 평가 여러 개가 동시에 실행되면 각 문항 기록에 다른 평가의 채점 시간이 합산됐고, 실행이 가장 긴 저희 구성이 가장 크게 손해를 봤습니다. 채점 호출을 별도 스레드로 옮긴 뒤 같은 구성의 기록 중앙값은 16.8초가 됐습니다.

평가기에는 실패 경로도 하나 있었습니다. 채점 모델 호출이 네트워크 오류로 한 번 실패하면 평가 전체가 중단됐습니다. 중간에 멈춘 회차의 부분 점수는 쓰지 않고 처음부터 재실행했습니다.

같은 조건에서 한 번 실행한 결과

관계형에서 차이가 가장 컸고(42 대 51), 교차 문서는 모든 구성에서 가장 낮았습니다(경쟁 35%, 저희 47%). 응답 시간은 경쟁 에이전트가 짧았습니다. 문항당 중앙값이 9.1초, 저희 상위 5개 구성이 16.8초였습니다.

평가셋도 따로 검수했습니다. 165문항의 질문과 기대 답변이 고객 원본 파일과 순서까지 같은지 확인했고, 실험한 다섯 구성이 모두 틀린 11문항은 기대 답변이 지정 문서 안에 실제로 있는지 대조했습니다. 답이 문서에 없어서 틀린 문항은 없었습니다. 그 11문항의 답변은 대부분 두세 개 규정 중 하나만 인용하고 있었습니다.

이 숫자가 말하지 않는 것

구성마다 한 번씩 실행한 결과입니다. 답변 모델의 온도가 1이라 회차 변동이 있습니다. 정답 문서의 검색 순위가 165문항 모두 같은 상태에서 근거 수 자동 구성을 재실행했더니 81.8%(135/165)였고, 첫 회차에서만 맞힌 문항이 6개, 재실행 회차에서만 맞힌 문항이 9개였습니다. 22문항 차이는 이 변동보다 크지만, 한 고객의 한 문항셋에서 한 채점 모델로 측정한 값입니다.

경쟁 쪽은 운영 설정 그대로 비교했고, 내부 검색 방식은 저희가 바꿀 수 없었습니다. 그래서 이 결과는 이 고객의 문서와 이 설정에서의 비교일 뿐, 두 제품의 일반적인 우열로 읽을 수는 없다고 봅니다.

돌아보면 이 비교에서 가장 쓸모 있었던 것은 점수표보다 조건표였던 것 같습니다. 숫자는 회차마다 몇 문항씩 움직였지만, 무엇을 맞췄고 무엇을 끝내 못 맞췄는지는 그대로 남았습니다.