FinanceBench 정확도 10%에서 57%로 향상: 실제로 성과를 낸 핵심 요소는 무엇인가
요약
금융 문서 Q&A를 위한 RAG 시스템의 정확도를 10%에서 57%로 향상시킨 기술적 과정을 다룹니다. 데이터 감사, CRAG 파이프라인 도입, 생성 모델 변경 등 실질적인 성능 개선 요소를 분석합니다.
핵심 포인트
- 데이터 누락 확인이 검색 최적화보다 우선되어야 함
- LangGraph를 활용한 명시적 그래프 구조가 에이전트 루프보다 효율적임
- 검색 성능(Recall) 향상보다 생성 모델 변경이 정확도에 더 큰 영향을 미침
- 하이브리드 검색과 재순위화(Reranking)를 통한 검색 품질 개선
한 달 전, 저는 금융 문서 질의응답(Q&A)을 위한 RAG (Retrieval-Augmented Generation) 시스템 구축을 시작했습니다. 첫 번째 테스트 결과: 20개 질문 중 2개만 정답. 마지막 테스트 결과: 인간의 레이블(label)을 기준으로 검증했을 때 100개 쿼리 중 57%의 정확도(accuracy)를 기록했습니다.
이 포스트는 어떤 개선 사항이 실제로 효과가 있었는지, 어떤 것이 효과가 없었는지, 그리고 저를 가장 놀라게 했던 하나의 발견에 대해 다룹니다.
설정 (The setup)
이 시스템은 84개 상장 기업의 SEC 공시 자료(10-K, 10-Q, 실적 보고서)에 관한 질문에 답변하며, Patronus AI의 FinanceBench를 통해 평가됩니다. 정답(ground truth)이 포함된 150개의 전문가 주석 Q&A 쌍이 사용되었습니다.
최종 스택: 생성(generation)을 위한 GPT-4o, 임베딩(embeddings)을 위한 text-embedding-3-small, 벡터 저장소(vector storage)를 위한 Qdrant (hybrid dense + BM25), 오케스트레이션(orchestration)을 위한 LangGraph (문서 등급 산정 기능이 포함된 CRAG 파이프라인), 재순위화(reranking)를 위한 BAAI/bge-reranker-base, 그리고 모든 청크(chunk)에 메타데이터 접두사(metadata prefixes)를 사용하는 컨텍스트 검색(contextual retrieval)입니다.
전체 리포지토리: financebench-rag-eval
진행 과정 (The progression)
| 단계 | Recall@6 | 정확도 (인간 검증) | 변경 사항 |
|---|---|---|---|
| 베이스라인 (Baseline) | — | 10% (20개 쿼리) | 첫 번째 테스트, 바닐라 RAG |
| ... | |||
| 두 가지가 눈에 띕니다. 검색(Retrieval) 성능은 83%에서 95%로 올라갔지만 정확도는 47%에 머물렀습니다. 그러다 생성 모델을 변경하자 정확도가 57%로 급등했습니다. 이에 대한 자세한 내용은 아래에서 다룹니다. |
실제로 효과가 있었던 것들
1. 코퍼스 감사 (Corpus audit) (+10%p 재현율(recall), 코드 변경 없음)
저는 하이브리드 검색(hybrid retrieval), 메타데이터 필터링(metadata filtering), 쿼리 라우팅(query routing)을 구현하는 데 2주를 보냈습니다. 재현율(Recall)은 83%에서 84%로 올라갔습니다. 그러다 감사를 실시한 결과, 5개의 문서가 전혀 수집(ingested)되지 않았고 2개는 PDF 추출 과정에서 손상되었다는 사실을 발견했습니다.
이를 수정하는 데는 30분이 걸렸습니다. 재현율은 94%로 급등했습니다.
검색 실패 사례 17건 중 9건은 단순히 벡터 저장소(vector store)에 들어있지 않았던 Johnson & Johnson 문서에서 발생했습니다. 파이프라인은 아무런 오류를 내지 않았습니다. 그저 다른 회사의 청크를 검색하여 자신 있게 틀린 답을 생성했을 뿐입니다.
교훈: 검색을 최적화하기 전에, 데이터가 실제로 모두 존재하는지 먼저 확인하십시오.
2. CRAG 파이프라인 (에이전트 루프 교체)
기존 파이프라인은 언제 검색(retrieve)하고 언제 답변할지를 결정하는 LangGraph 에이전트였습니다. 때때로 5~6번의 검색 호출을 수행하며 관련 없는 기업의 노이즈 데이터를 가져오기도 했습니다.
저는 이를 명시적인 그래프(explicit graph)인 query_analysis → retrieve → rerank → grade_documents → generate로 교체했습니다. 만약 채점(grading) 단계에서 청크(chunk)가 부적절하다고 판단하면, 메타데이터 필터(metadata filter)를 완화하고 한 번 더 재시도합니다.
이를 통해 파이프라인은 예측 가능해졌고, 비용이 저렴해졌으며(API 호출 감소), 디버깅이 쉬워졌습니다. LLM이 흐름을 결정하는 대신, 모든 단계가 고정된 역할을 수행하게 되었습니다.
3. 문맥적 검색 접두사 (Contextual retrieval prefixes)
SEC 공시 자료는 기업 간에 거의 동일한 언어를 사용합니다. "Net revenues increased(순매출 증가)"라는 문구는 모든 10-K 보고서에 등장합니다. 그래서 저는 임베딩(embedding)을 하기 전에 각 청크 앞에 메타데이터를 접두사로 붙였습니다:
Company: Johnson & Johnson | Document: 10K | Year: 2022
이렇게 하면 임베딩이 단순히 무엇을 말하는지가 아니라, 해당 청크가 어디에서 왔는지를 포착하도록 변경됩니다. 쿼리 시점의 메타데이터 필터링과 결합하여, 기업 간 검색 오류를 줄일 수 있었습니다.
4. GPT-4o-mini에서 GPT-4o로 전환 (+10%p 정확도 향상)
이것이 이번 프로젝트의 가장 큰 발견이었습니다.
모든 검색 개선 작업을 마친 후에도 정확도는 약 47%에 머물러 있었습니다. 재현율(Recall)은 95%였습니다. 파이프라인이 올바른 문서를 가져오고는 있었지만, 모델이 잘못된 숫자를 추출하거나 정답이 문맥(context) 안에 있음에도 불구하고 "모르겠습니다"라고 답하고 있었습니다.
저는 생성(generation) 모델을 GPT-4o-mini에서 GPT-4o로 교체했습니다. 정확도는 약 47%에서 약 57%로 올라갔습니다. 검색, 청크, 프롬프트는 모두 동일했습니다. 단지 더 나은 모델을 사용했을 뿐입니다.
병목 현상(bottleneck)은 결코 검색이 아니었습니다. 그것은 금융 데이터를 추론하는 생성 모델의 능력이었습니다.
효과가 없었던 것들
하이브리드 검색 (Hybrid retrieval: dense + BM25). RRF 퓨전(RRF fusion)과 함께 FastEmbedSparse를 통해 BM25를 추가했습니다. BM25가 정확한 숫자 일치를 잡아내기 때문에 충실도(Faithfulness)는 개선되었지만(+0.78), 정밀도(Precision)와 MRR은 하락했습니다. BM25가 의미론적으로 관련 없는 키워드 매칭 청크들을 가져오면서, 올바른 청크들의 순위를 뒤로 밀어냈기 때문입니다.
보정(Calibration)이 없는 Judge v1. 제 LLM Judge는 100개의 답변 중 63개가 정답이라고 말했습니다. 하지만 30개의 인간 라벨(Human labels)과 대조해 본 결과, 실제 숫자는 47이었습니다. Judge가 수치적 정확성(Numerical accuracy)이 아닌 유창성(Fluency)을 평가했기 때문에 점수를 34% 부풀린 것입니다. 정답이 "$2,018M"인데 "$1,608M"라고 답한 경우, 문장 구조가 잘 잡혀 있다는 이유로 5/5점을 받았습니다.
저는 명시적인 수치 비교 규칙을 적용한 더 엄격한 Judge(v2)를 구축했습니다. 그 결과 TNR(True Negative Rate)이 0.75에서 0.94로 향상되었습니다.
평가 시스템 (The eval system)
이 포스트의 모든 수치는 다단계 평가(Multi-tier eval)에서 도출되었습니다:
Tier 1 (검색 (Retrieval)): Recall@6, Precision@6, MRR. 파이프라인의 어느 단계에서 실패가 발생하는지 파악할 수 있도록 생성(Generation) 단계와 분리하여 측정했습니다.
Tier 2 (생성 (Generation)): LLM-as-judge를 사용하여 문맥 관련성(Context relevance), 충실도(Faithfulness), 그리고 정답(Ground truth) 대비 답변의 정확성(Answer correctness)을 점수화했습니다. 두 가지 Judge 버전이 사용되었습니다: v1 (관대한, 유창성 편향) 및 v2 (엄격한, 수치 허용 오차 적용).
보정 (Calibration): 모든 Judge는 30개의 인간 라벨을 통해 검증되었습니다. TPR(True Positive Rate)과 TNR을 보고했습니다. 최종 보정 결과: TPR=0.82, TNR=0.92. 이 단계가 없었다면 실제 47% 대신 63%의 정확도를 보고했을 것입니다.
비용 (Cost)
| 지표 (Metric) | 값 (Value) |
|---|---|
| 쿼리당 비용 (Cost per query) | $0.017 |
| ... | ... |
내가 다르게 했을 일들
어떤 알고리즘 작업에 착수하기 전에 코퍼스 감사(Corpus audit)부터 시작했을 것입니다. 그랬다면 2주를 아낄 수 있었을 것입니다.
평가 인프라(Eval infrastructure)를 4주 차가 아닌 1주 차에 구축했을 것입니다. 측정 없이는 추측만 할 뿐이었습니다. 측정이 뒷받침되자 모든 변경 사항에 대해 명확한 전/후 비교가 가능했습니다.
생성 모델(Generation model)을 더 일찍 테스트했을 것입니다. 저는 GPT-4o-mini가 "충분히 좋다"고 가정하고 검색(Retrieval) 최적화에 몇 주를 소비했습니다. 모델 교체가 마지막 실험이 아니라 첫 번째 실험이 되었어야 했습니다.
다음 단계
57%의 정확도는 FinanceBench에 대한 RAG로서 경쟁력이 있습니다 (이 벤치마크에서 전체 문서 문맥을 가진 GPT-4의 점수는 약 60-65%입니다). 하지만 개선의 여지가 있습니다: PDF로부터의 더 나은 테이블 추출(Table extraction), 금융 테이블을 보존하기 위한 더 큰 청크 크기(Chunk sizes), 그리고 복잡한 계산을 위한 다단계 추론(Multi-step reasoning) 등이 있습니다.
이 사항들은 리포지토리(Repo)에 향후 과제(Future work)로 문서화되어 있습니다.
Repo: financebench-rag-eval
참고 자료 (References)
- FinanceBench — Patronus AI
- 6 RAG Evals — Jason Liu
- LLM Evals FAQ — Hamel Husain
- AI Builder's Handbook — LevelUp Labs
- LangGraph 문서
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기