Molayo

© 2026 Molayo

Dev.to헤드라인2026. 05. 31. 00:00

금융 RAG에서 발견한 5가지 실패 모드 (그리고 실제로 중요했던 한 가지)

요약

금융 RAG 시스템 구축 과정에서 겪은 시행착오와 성능 개선 사례를 다룹니다. 알고리즘 개선보다 데이터 수집 및 추출 과정의 무결성을 검증하는 코퍼스 감사가 성능 향상에 훨씬 결정적임을 보여줍니다.

핵심 포인트

  • 알고리즘 개선보다 데이터 누락 및 손상 확인이 우선되어야 함
  • 코퍼스 감사만으로 Recall@6 지표를 84%에서 94%로 개선
  • 하이브리드 검색 등 복잡한 기법보다 데이터 품질이 핵심
  • PDF 추출 과정에서의 데이터 손실 가능성을 반드시 점검할 것

금융 문서 질의응답(Q&A)을 위한 저의 RAG (Retrieval-Augmented Generation) 시스템은 53%의 정확도에서 정체되어 있었습니다. 저는 2주 동안 하이브리드 검색 (Hybrid Retrieval), 메타데이터 필터링 (Metadata Filtering), 그리고 쿼리 라우팅 (Query Routing)을 구현하는 데 시간을 보냈습니다. 정확도는 58%로 올라갔습니다.

그 후 코퍼스 감사 (Corpus Audit)를 실시한 결과, 5개의 문서가 전혀 수집(Ingested)되지 않았고 2개는 손상되었다는 사실을 발견했습니다. 이것을 수정하는 것만으로도 재현율 (Recall)이 83%에서 94%로 상승했습니다.

프로젝트 전체에서 가장 영향력 있었던 개선 작업은 단 30분이 걸렸으며, 새로운 코드는 단 한 줄도 작성하지 않았습니다.

설정 (The setup)

간략한 배경 설명: 저는 SEC 공시 자료에 대해 전문가가 주석을 단 150개의 Q&A 쌍을 포함하는 벤치마크인 FinanceBench (Patronus AI)를 기준으로 평가되는 RAG 시스템을 구축하고 있습니다. 파이프라인은 생성을 위한 GPT-4o-mini, 임베딩 (Embeddings)을 위한 text-embedding-3-small, 그리고 벡터 스토어 (Vector Store)로 Qdrant를 사용합니다. 인간의 레이블 (Human Labels)에 맞춰 보정된 LLM-as-judge를 포함한 전체 평가 인프라가 구축되어 있습니다 ([첫 번째 포스트에서 평가 설정을 다룹니다][https://dev.to/joaopaulotr/building-an-evaluation-harness-for-financial-rag-what-i-learned-about-llm-as-judge-calibration-5030]).

2단계 이후, 저는 기준점(Baseline)을 확보했습니다: Recall@6은 0.83이었고, 100개의 쿼리 중 약 47개가 정확하게 답변되었습니다 (인간 레이블에 의해 검증됨).

5가지 실패 모드 (The 5 failure modes)

저는 100개의 쿼리 평가 세트에 있는 모든 오류를 분류했습니다. 제가 발견한 내용은 다음과 같습니다:

1. 누락된 문서 (가장 큰 문제)

저는 왜 Johnson & Johnson 관련 쿼리가 항상 실패하는지 디버깅하고 있었습니다. 17번의 검색 실패 중 9번이 J&J 문서였습니다. 모든 SEC 공시 자료는 거의 동일한 언어를 사용하기 때문에, 저는 이것이 의미론적 유사성 (Semantic Similarity) 문제라고 가정했습니다.

하지만 아니었습니다. 문서는 다운로드조차 되지 않았던 것입니다.

감사 결과, 데이터셋의 84개 문서 중 5개가 제 벡터 스토어에서 누락되었고, 2개는 PDF 추출 과정에서 손상되었다는 것이 밝혀졌습니다 (AMD와 KraftHeinz는 150개 이상의 청크 (Chunks) 대신 각각 5개와 0개의 청크를 가지고 있었습니다). 이를 수정한 후, 검색 실패는 16회에서 6회로 감소했습니다.

지표 (Metric)코퍼스 (Corpus) 수정 전코퍼스 (Corpus) 수정 후차이 (Delta)
Recall@60.8400.940+0.100
검색 실패 (Retrieval misses)166-10

이것은 제가 계속해서 되새기는 교훈입니다. 근본 원인은 불완전한 데이터였음에도 불구하고, 저는 알고리즘 개선을 구현하는 데 며칠을 허비했습니다. 프로덕션 (Production) 환경에서는 이런 일이 끊임없이 발생합니다. 조용히 실패하는 파이프라인 (Pipelines), 누락되는 문서들, 처리 과정에서 손상되는 파일들 말입니다. 재순위화 (Reranking)나 쿼리 재작성 (Query rewriting)을 아무리 많이 해도 누락된 데이터는 해결할 수 없습니다.

2. 동일 기업 내 문서 간 혼동 (Cross-document confusion within the same company)

누락되었던 J&J 문서를 인제스션 (Ingesting)한 후, 새로운 문제가 나타났습니다. 리트리버 (Retriever)가 J&J의 2023년 8-K에 대한 쿼리임에도 불구하고 가끔 J&J의 2022년 10-K에서 청크 (Chunks)를 가져오는 현상이 발생했습니다. 동일한 기업이지만, 잘못된 문서를 가져온 것입니다.

제 메타데이터 필터 (Metadata filter)는 쿼리에서 기업명을 추출하여 검색 전 Qdrant를 필터링했습니다. 하지만 맞춤 문서와 틀린 문서가 모두

결과적으로 정밀도 (Precision)는 0.422에서 0.405로 떨어졌고, MRR은 0.646에서 0.594로 하락했습니다. BM25는 의미론적으로 관련이 없는 키워드 매칭 청크 (keyword-matching chunks)를 끌어들여, 정답 청크의 순위를 뒤로 밀어냈습니다. 모든 이론적인 개선 사항이 실제 적용 시 효과가 있는 것은 아닙니다.

5. 판사 인플레이션 (Judge inflation)

이 문제는 미묘하며 놓치기 쉽습니다.

저의 LLM 판사 (A|GT, 정답(ground truth) 포함)는 100개의 답변 중 63개가 정답이라고 말했습니다. 하지만 30개의 인간 라벨 (human labels)과 대조해 본 결과, 실제 숫자는 약 47개였습니다. 판사가 점수를 34% 부풀린 것입니다.

이유는 무엇일까요? 판사가 수치적 정확도 (numerical accuracy)가 아닌 추론 품질과 방법론을 평가했기 때문입니다. 정답이 "$2,018M"일 때 "$1,608M"라고 답한 답변이, 설명 방식이 잘 구조화되어 있다는 이유로 5/5점을 받은 것입니다.

저는 명시적인 수치 비교 규칙을 포함한 더 엄격한 판사 (v2)를 구축했습니다. 이를 통해 추정치를 100개 중 51개로 낮추어 실제 수치에 훨씬 가깝게 만들었습니다. 하지만 과잉 교정이 발생했습니다. TPR (True Positive Rate)이 0.93에서 0.71로 떨어졌는데, 이는 이제 정답의 29%를 거부한다는 의미입니다.

판사 (Judge)보고된 정답 수TPRTNR인간 대비 인플레이션
v1 (관대한)63/1000.930.75+16
...

완벽한 판사는 없습니다. 당신은 편향 (bias)을 선택해야 합니다. 위양성 (false positives, 틀린 답을 승인)을 선택할 것인지, 아니면 위음성 (false negatives, 맞는 답을 거부)을 선택할 것인지 말입니다. 유일한 정답 (ground truth)은 인간의 라벨입니다.

실제로 유의미한 변화를 만든 것

전체 진행 과정은 다음과 같습니다:

단계 (Phase)Recall@6정확도 (인간 기준)변경 사항
Phase 2 (베이스라인)0.830~47/100없음, 첫 번째 측정
...

불편한 발견은 이것입니다: 검색 (retrieval) 성능은 크게 향상되었으나 (83%에서 94%로), 실제 정확도는 약 47%에 머물렀습니다. 병목 현상 (bottleneck)이 검색에서 생성 (generation)으로 이동한 것입니다. 모델은 이제 올바른 문서를 가져오지만, 여전히 틀린 숫자를 생성합니다.

구현하지 않은 것 (그리고 그 이유)

접근 방식 (Approach)제외한 이유
의미론적 청킹 (Semantic chunking)전체 재수집 (re-ingestion)이 필요하며, 현재 청킹 방식 대비 효과가 불확실함
...

이것들은 나쁜 아이디어가 아닙니다. 단지 결정을 미룬 것뿐입니다. 핵심은 검색 (retrieval) 단계의 반복을 언제 멈추고, 현재 병목 현상 (bottleneck)이 발생하고 있는 생성 (generation) 품질을 살펴보기 시작해야 하는지를 아는 것입니다.

내가 배운 것들 (What I learned)

데이터 품질이 알고리즘보다 중요합니다. 제가 시도한 가장 정교한 해결책 (RRF를 이용한 하이브리드 검색 (hybrid retrieval))은 두 가지 지표에서 부정적인 영향을 미쳤습니다. 반면, 가장 단순한 해결책 (누락된 파일 다운로드)은 프로젝트 전체에서 가장 큰 긍정적 영향을 미쳤습니다.

평가 (eval)는 평가자 (judge)만큼만 훌륭할 수 있습니다. 세 가지 서로 다른 평가 방식은 각각 63%, 51%, 47%라는 세 가지 다른 정확도 수치를 보여주었습니다. 인간의 보정 (human calibration)이 없었다면, 저는 63%라고 보고하고 파이프라인이 개선되고 있다고 믿었겠지만, 실제로는 그렇지 않았을 것입니다.

병목 현상이 언제 이동하는지 파악하세요. 검색을 계속 최적화할 수도 있겠지만, 재현율 (Recall)이 94%인 상황에서 남은 오류들은 생성 (generation) 단계에 있습니다. 다음 개선 사항은 모델이 문서를 어떻게 찾느냐가 아니라, 모델이 숫자를 어떻게 추출하고 추론 (reasoning)하느냐를 목표로 삼아야 합니다.

Repo: financebench-rag-eval

참고 문헌 (References)

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0