Salesforce는 자사 RAG 앱이 테스트에서 90%를 기록했지만 실제 고객에게는 46%였던 이유를 밝혀냈다

Salesforce의 검색 증강 생성(RAG) 파이프라인은 표준 텍스트 검색 벤치마크에서 90%를 넘는 정확도를 기록했지만, 여러 페이지에 걸친 표와 병합된 셀이 있는 보험 약관처럼 복잡하고 고객을 대표하는 엔터프라이즈 문서로 테스트했을 때는 약 46%로 떨어졌다. 이 격차는 두 분기에 걸친 고객 에스컬레이션 이후에야 드러났고, 당연한 용의자는 LLM 자체였다.

모델을 교체하거나 프롬프트를 다시 작성하는 대신, 엔지니어링 팀은 각 오답에서 거꾸로 거슬러 올라갔다. 검색된 컨텍스트가 완전했는가? 그렇지 않다면 검색이 잘못된 청크를 선택했는가, 아니면 청킹이 관련 정보를 분할했는가, 아니면 파싱이 먼저 정보를 잃었는가? 테스트 결과 표 헤더가 페이지 나눔을 넘어 데이터와 분리되고 있었고, 고정 크기 청킹이 절차를 임의의 토큰 경계에서 잘라내어 의미를 부여하던 제목과 다이어그램을 제거하고 있었다.

그런 다음 팀은 한 번에 하나의 파이프라인 단계를 변경하고 동일한 단계별 벤치마크를 다시 실행하여 각 개선 효과를 귀속시켰다. 복잡한 표와 차트를 모델 기반 처리로 라우팅하는 페이지 수준의 '지능형 파싱(Intelligent Parsing)'을 추가하자 단계별 기준선이 65.1%에서 84.4%로 올랐다. 각 청크를 메타데이터와 질문 표현으로 보강하고, 컨텍스트 용량을 512개에서 8,000개 토큰으로 확장한 임베딩 모델을 결합하자 2.4포인트가 더해져 86.8%가 되었다. 전체 변경 사항을 통틀어 더 넓은 엔터프라이즈 문서 벤치마크의 정확도는 약 46%에서 90% 이상으로 상승했다.

모델을 탓하는 대신, 한 번에 하나의 격리된 단계씩 파이프라인을 역순으로 디버깅했다

파이프라인을 단계별로 역순으로 테스트함으로써 추측하는 대신 파싱, 청킹, 보강, 임베딩, 검색 중 무엇이 실제로 각 오답을 일으켰는지 분리해냈다.

동일한 벤치마크를 다시 실행하기 전에 정확히 하나의 단계만 변경함으로써 각 개선 효과를 65.1%에서 84.4%, 다시 86.8%로 귀속시킬 수 있었고, 하나의 불투명한 통합 점수로 뭉뚱그리지 않았다.

구조적 복잡성(단순 텍스트 대 표/차트/다이어그램)에 따라 페이지를 라우팅함으로써 모든 문서를 값비싼 모델 기반 파싱으로 보내는 일을 피했다.

수정은 더 똑똑한 모델에게 누락된 컨텍스트를 보상하도록 요청하는 대신, 의미가 상실되던 지점, 즉 데이터와 분리된 헤더와 토큰 경계에서 분할된 절차를 겨냥했다.

AI 시스템이 벤치마크를 통과했음에도 프로덕션에서 실패할 때는 모델을 건드리기 전에 각 파이프라인 단계를 분리하여 다시 테스트하라. 실패는 보통 모델의 상류에서 발생한다.

Salesforce는 또한 소규모 문서 인덱싱을 Spark 기반 배치 아키텍처에서 서비스 기반 저스트 인 타임(just-in-time) 아키텍처로 전환하여 인덱싱 시간을 3~4배 단축했고, 30분 이상에서 약 7~10분으로 줄였다. 팀은 여러 문서에 걸친 지식 그래프를 순회하여 다중 홉 질문에 답하는 GraphRAG를 2026년 11월 정식 출시(GA)할 예정이라고 밝혔다.