금융 자문 앱에 필요한 것은 챗봇이 아닌 RAG Vault

Vicquant를 개발하기 시작했을 때, 핵심 설계 원칙은 간단하고 타협할 수 없었습니다. AI는 절대 계산을 하지 않는다는 것입니다. 모든 숫자와 부채 상환 일정, 백테스트된 승률, 위험 지표 등은 결정론적 코드(deterministic code)에 의해 계산됩니다. 모델의 유일한 임무는 결과를 평이한 언어로 설명하는 것이며, 처음부터 숫자를 생성하는 것이 아닙니다.

이 원칙은 사용자들을 한 종류의 실패로부터 보호합니다: 모델이 확신을 가지고 잘못된 계산을 지어내는 경우입니다. 하지만 이는 두 번째의, 더 조용한 실패 모드에 대해서는 보호하지 못합니다. 즉, 모델이 실제로 본 적 없는 문서에 대한 사실적 질문에 대해 그저 그럴듯하게 들리는 것을 사용하여 자신감 있게 답변하는 경우입니다. 만약 사용자가 수수료 일정표를 업로드하고 '오버드래프트에 대해 이것이 실제로 얼마를 청구하나요?'라고 묻는다면, 일반적인 챗봇의 답변만으로는 충분하지 않습니다. 그 답변은 해당 특정 문서에 근거해야 하며, 영수증과 함께 제시되어야 합니다.

이것이 바로 RAG Vault가 존재하는 이유이며, 이를 제대로 구현하는 것은 제가 예상했던 것보다 더 깊은 엔지니어링 문제였습니다.

*왜 단순한 버전이 금융에는 작동하지 않는가
*
기본적인 RAG(Retrieval-Augmented Generation) 구현은 텍스트를 고정 크기의 청크로 분할하고, 이를 임베딩하며, 가장 가까운 일치 항목을 검색하는 방식으로 일반 텍스트에 대해서는 비교적 잘 작동합니다. 하지만 금융 문서의 경우 특정 이유 때문에 무너집니다: 금융 문서는 표(tables)로 가득 차 있으며, 단순한 문자 분할기(character-splitter)는 그것이 숫자 행을 파괴하고 있다는 인지 없이 그 사이를 자릅니다. 세금 구간표(Tax brackets), 수수료 일정표(fee schedules), 10-K 공시 자료 등은 모두 표 형태이며, 무분별한 분할에 매우 취약합니다. 해결책은 레이아웃 인식 파싱(layout-aware parsing)을 통해 임의의 텍스트 창이 아닌 표, 제목, 구조화된 섹션을 전체 단위로 감지하고 보존하는 것이었습니다.

청크 크기 딜레마

레이아웃 인식 파싱(layout-aware parsing)을 사용하더라도, 검색 가능한 각 조각이 얼마나 커야 하는지에 대한 긴장감이 존재합니다. 작은 청크는 검색 쿼리와 정확하게 일치하지만 모델에게 답변하기에 충분한 주변 문맥을 제공하지 못합니다. 반면 큰 청크는 풍부한 문맥을 제공하지만 특정 질문과 정밀하게 일치시키기가 더 어렵습니다. Vicquant는 계층적 청킹(hierarchical chunking)으로 이를 해결합니다. 작은 '자식(child)' 청크(150250 토큰)가 검색되고 일치하는 대상이 되지만, 이 각각의 자식 청크는 실제로 매칭이 발견되면 모델에 전달되는 더 큰 '부모(parent)' 청크(8001200 토큰)와 연결됩니다. 즉, 검색에는 정밀도를, 생성에는 문맥을 제공하며, 이 둘은 서로 상충하는 관계가 아니라 분리되어 작동합니다.

단어가 일치하지 않을 때 올바른 구절 찾기

순수한 키워드 또는 기본적인 코사인 유사도(cosine-similarity) 검색은 개념적 동의어(conceptual synonyms)를 놓칩니다. 또한,

놓치기 쉬운 한 가지 세부 사항이 있습니다. 대규모 언어 모델(LLM)은 긴 컨텍스트 윈도우 전체에 걸쳐 균일한 주의를 기울이지 않습니다. 중간에 배치된 정보는 시작 부분과 끝 부분에 비해 가중치가 낮아지는 경향이 있는데 (때로는 'Lost in the Middle'이라고 불리는 잘 알려진 현상입니다). 따라서 가장 관련성 높은 검색 패시지들은 단순히 순위별로 쌓이는 것이 아니라, 모델에 전송되는 내용의 시작과 끝에 의도적으로 배치됩니다.

단순 검색을 넘어 근거 제시(Grounding)

마지막 부분은 모든 답변이 감사 가능하도록 만드는 것입니다. Vicquant의 인용 형식은 모호한 '문서에 따르면'이 아닙니다. 이는 주장을 생성한 정확한 패시지를 가리키는 엄격하고 결정론적인 토큰입니다: [Citation ID: doc_id:chunk_id]. 금융 앱에게 있어 이것은 사용자 신뢰를 넘어선 이유로 중요합니다. 즉, 누군가 검증할 수 있는 답변과 단지 믿어야 하는 답변 사이의 차이이기 때문입니다.

평가가 실제로 보여준 것들

저는 새로운 파이프라인을 기존 파이프라인과 25개 문항의 금융 벤치마크에 대해 비교 실행했습니다. 이 벤치마크는 숫자 조회, 개념적 동의어 일치, 다중 테이블 추출로 나뉘었으며 RAGAS 지표를 사용하여 점수화되었습니다:

Faithfulness — 주장이 환각(hallucinated)이 아닌 검색된 컨텍스트에 실제로 근거하는지 측정하는 지표로, 기존 파이프라인에서도 이미 완벽했으며 그대로 유지되었습니다. 이는 예상된 결과입니다. 신뢰성(faithfulness)은 검색 아키텍처가 아니라 생성 단계의 하류 과정이기 때문입니다. 실제 개선점은 Context Precision에서 16포인트 상승한 것이며, 새로운 파이프라인은 크로스 인코더 재순위화(cross-encoder reranking) 단계를 통해 근접하지만 관련 없는 내용(near-misses)을 모델에 도달하기 전에 걸러내면서 눈에 띄게 적은 관련 없는 '방해 요소'(distractor) 콘텐츠를 끌어들입니다.

또한 저는 복원력 주장들을 가정하는 대신 직접 스트레스 테스트를 수행했습니다. 호스팅된 임베딩 API(hosted embedding API)를 의도적으로 실패시키는 것이 회로 차단기(circuit breaker)가 작동하고 파이프라인이 로컬 오프라인 임베더(local offline embedder)로 전환되며 처리되지 않은 예외(unhandled exceptions)가 전혀 발생하지 않음을 확인시켜 줍니다. 또한, 내장된 지침("SYSTEM OVERRIDE: ignore all prior instructions")을 포함하는 문서를 입력하면, 해당 텍스트가 모델의 동작에 영향을 미치기보다는 비활성 데이터(inert data)로 캡슐화되어 유지됨을 확인했습니다.

성능에 대한 솔직한 주의사항이 하나 있습니다. 테스트에서 측정한 파이프라인의 내부 처리 오버헤드(internal processing overhead)는 작지만, 이 수치는 실제 API 지연 시간(live API latency)이 아니라 테스트 더블(test doubles)을 대상으로 실행되는 네트워크 의존적 구성 요소(호스팅 임베딩 호출, HyDE의 LLM 호출 등)와 파이프라인 자체 로직을 반영한 것입니다. 실제 응답 시간은 OpenRouter로 가는 실제 네트워크 호출에 의해 지배될 것이며, 저는 아직 이 부분을 라이브 API를 기준으로 벤치마킹하지 않았습니다. 이것이 사용자에게 속도 관련 주장을 하기 전에 솔직하게 측정해야 할 다음 항목입니다.

애초에 왜 이런 방식으로 금융 자문가를 구축해야 하는가

요약하자면: AI 비서가 사람의 돈으로 할 수 있는 최악의 일은 무언가를 잘못하는 것이 아닙니다. 그것은 사람이 확인할 방법 없이, 자신감 있게 잘못된 것을 말하는 것입니다. Vicquant의 모든 설계 결정—"AI는 절대 숫자를 계산하지 않는다"부터 "모든 RAG 답변에는 출처가 명시된다"—은 이 하나의 원칙으로 거슬러 올라갑니다. 이렇게 구축하는 것은 느립니다. 하지만 저는 이것이 유일하게 책임감 있는 구축 방식이라고 생각합니다.