Citation-Guard: 규제 대상 핀테크를 위한 프로덕션 RAG 패턴

Naive RAG는 데모에서는 통과할지 몰라도 감사(Audit)에서는 실패합니다. Citation-guard 패턴은 핀테크 AI가 정직함을 유지하도록 돕습니다: 인용(Citation)과 함께 검색하고, 숫자를 인용하며, 불확실할 때는 답변을 거부하고, 배포하기 전에 검증하십시오.

한 자산 관리 플랫폼은 고객의 질문에 평이한 영어로 답변하는 AI 어시스턴트를 시연했습니다. 이는 잘 작동하는 듯 보였으나, 누군가 중도 인출 수수료에 대해 묻자 잘못된 숫자를 반환했습니다. 그 숫자는 매우 확신에 찬 어조로 읽혔습니다. 만약 고객이 그 정보에 따라 행동한다면, 당신은 규제 관련 민원에 직면하게 됩니다.

대부분의 핀테크 AI는 강력한 데모와 규제 대상 사용자 앞에 내놓을 수 있는 시스템 사이의 간극에서 무너집니다. 우리는 이를 끊임없이 목격합니다. 우리는 핀테크 기업이 프로덕션에서 저지르는 10가지 RAG 아키텍처 실수에서 더 광범위한 사례들을 정리했습니다. 이 글에서는 기업을 진짜 곤경에 빠뜨리는 실패 사례인 '확신에 찬 오답'을 다룹니다.

꼬리(The tail)가 전체 문제다

벤치마크 결과는 92%의 정확도를 나타냈습니다. 소비자용 앱이라면 92%는 좋은 제품을 만듭니다. 하지만 금융 분야에서 잘못된 8%는 가장 큰 책임(Liability)을 수반하는 예외 사례(Edge cases)에 해당하며, 그 답변은 올바른 92%와 동일한 어조로 전달됩니다.

금융 결정을 내리는 사람에게 "대체로 정확한" 시스템을 배포할 수는 없습니다. 따라서 실제 엔지니어링 질문은 어떻게 하면 시스템이 틀릴 상황에서 답변을 거부하게 만들 것인가 하는 점입니다.

우리는 규제 문서, 고객 커뮤니케이션, 금융 데이터에 대한 RAG를 포함하여 여러 프로덕션 핀테크 시스템에 이를 적용해 왔습니다. 컴플라이언스 검토(Compliance review)를 통과하는 이 패턴을 우리는 citation-guard라고 부릅니다. 파이프라인은 다음과 같습니다:

질의 (Query)
  -> 검색 (Retrieve) (벡터 검색 (Vector search) -> 출처 참조가 포함된 순위가 매겨진 구간 (Ranked spans WITH source refs))
  -> 생성 (Generate) (모든 주장은 특정 구간을 인용하며, 숫자는 직접 쓰지 않고 인용함)
...

네 가지 규칙이 이를 가능하게 합니다.

규칙 1 — 인용과 함께 검색: 모든 주장은 소스 구간에 매핑되어야 함

대부분의 파이프라인은 청크(Chunks)를 검색하여 프롬프트(Prompt)에 집어넣고 모델이 이를 합성(Synthesize)하도록 둡니다. 환각(Hallucination)은 바로 그 합성 과정에서 발생합니다. 모델은 출처를 혼합하고 빈틈을 메우며, 어떤 문장이 어디에서 왔는지 구분할 수 없게 만듭니다.

Citation-guard는 이 계약을 뒤집습니다. 검색 (Retrieval) 단계에서 문서, 섹션, 문자 범위 (character range)와 같은 정체성을 가진 스팬 (span)을 반환합니다. 그러면 모델은 모든 사실적 문장에 스팬 참조 (span reference)를 부착합니다.

여러분의 검색 레이어 (retrieval layer)가 한계치를 결정합니다. 청킹 (Chunking), 임베딩 (embeddings), 그리고 벡터 스토어 (vector store)가 모두 중요합니다. 저희는 Postgres pgvector vs Pinecone에서 해당 레이어를 벤치마킹했으며, RAG for reliable AI에서 정확도 기술들을 다루었습니다. Citation-guard는 훌륭한 검색 위에 구축되는 것이지, 검색을 대체하는 것이 아닙니다.

만약 어떤 주장이 검색된 스팬으로 추적될 수 없다면, 그것은 출력되지 않습니다. 이 규칙은 가장 최악의 실패 모드인 '출처가 없는 그럴듯한 문장'을 제거합니다.

규칙 2 — 숫자는 의역하지 말고 인용할 것

숫자는 패턴 매칭 (pattern-matching)이 여러분을 배신하는 지점입니다. "$10,000"가 "$100,000"가 되거나, "3.5%"가 "3.05%"가 될 수 있습니다. 두 경우 모두 권위 있어 보입니다.

따라서 시스템은 스팬에서 숫자 값을 추출하여 작성된 그대로 렌더링합니다. 모델은 어떤 숫자가 관련이 있는지를 선택할 뿐입니다. 모델이 숫자를 직접 작성하는 일은 결코 없습니다. 값은 소스 문서에서 오며, 모델의 다음 토큰 확률 (next-token probability)에서 오는 것이 아닙니다.

규칙 3 — 추측하기보다 답변을 거부할 것

어시스턴트를 항상 도움이 되게 만들려는 본능이 있습니다. 규제 대상인 금융 분야에서 그 본능은 부채 (liability)가 됩니다. 문맥이 부족할 때 추측하는 어시스턴트는, 답변을 거부하고 사용자를 상담원에게 연결하는 어시스턴트보다 더 큰 피해를 줍니다.

여러분의 위험 허용 범위 (risk tolerance)에 맞춰 검색 신뢰도 하한선 (retrieval-confidence floor)을 조정하십시오. 높은 답변 거부율을 겪어야 하는 실패가 아니라, 여러분이 선택한 비용으로 취급하십시오. 금융에서는 틀린 답을 하는 것보다 답변을 거부하는 것이 낫습니다.

규칙 4 — 출력하기 전에 검증할 것

생성 (generation)과 전달 (delivery) 사이에 가드 (guard)를 추가하십시오. 답변이 사용자에게 도달하기 전에, 검증 단계 (verification pass)를 통해 각 주장 (claim)을 인용한 구간 (span)과 대조합니다. 즉, 주장이 뒷받침되는지, 그리고 인용된 숫자가 일치하는지를 확인하는 것입니다. 여기에는 하나의 예/아니오 (yes/no) 질문에만 집중하는 저렴하고 작은 모델 (smaller model)이 효과적입니다. 이를 통해 시스템은 단순히 답변을 내뱉는 것이 아니라, 답변에 대해 책임을 지게 됩니다.

올바른 지표를 측정하십시오

정확도 (Accuracy)만으로는 실패 모드 (failure mode)를 숨길 수 있습니다. 대신 다음 지표들을 추적하십시오:

• 인용 범위 (Citation coverage) — 유효한 소스 구간 (source span)을 가진 사실적 문장의 비율. 100%를 목표로 합니다.
• 수치 충실도 (Numeric fidelity) — 소스와 정확히 일치하는 숫자의 비율.
• 거절률 (Abstention rate) — 시스템이 답변을 거부하는 빈도. 이를 지속적으로 모니터링하십시오.
• 감사 추적 가능성 (Audit traceability) — 과거의 어떤 답변에 대해서도, 어떤 구간이 해당 답변을 생성했는지 재구성할 수 있는가? 규제 대상인 금융 분야에서는 반드시 그래야 합니다.

비용 측면

Citation-guard는 공짜가 아닙니다. 이는 검색 규율 (retrieval discipline), 검증 단계 (verification pass), 그리고 항상 작동하는 신탁 (oracle)을 기대하는 사람들을 좌절시킬 수 있는 거절률 (abstention rate)을 추가합니다. 지연 시간 (Latency)은 증가하며, 검색 (retrieval) 성능이 향상되어 상승하기 전까지는 인용 범위 (coverage)가 일시적으로 떨어질 수 있습니다.

그 대가로 당신은 방어 가능한 답변을 얻게 됩니다. 컴플라이언스 (compliance) 부서에서 특정 숫자가 어디에서 왔는지 물을 때, 시스템은 모델 가중치 (model weights)에 대해 어깨를 으쓱하는 대신 문서, 섹션, 그리고 특정 구간을 지목합니다.

우리의 시스템 전반에 걸쳐, 모델 크기는 수치에 큰 영향을 주지 않았습니다. 가드레일 (guardrails)이 수치를 변화시켰습니다. 환각 (hallucinations)을 해결하기 위해 더 크고 비싼 모델을 찾는 팀은 잘못된 문제를 풀고 있는 것입니다.

요약 (Takeaway)

단순한 RAG는 평균적인 케이스 (average case)에 최적화되어 있으며 데모용으로는 훌륭합니다. 규제 대상인 핀테크 (fintech)는 꼬리 부분 (tail, 극단적인 케이스)에서 결정됩니다. 꼬리 부분을 위해 구축하십시오. 모든 주장을 인용하고, 모든 숫자를 인용하며, 불확실할 때는 거절하고, 배포하기 전에 검증하십시오. 그러한 아키텍처가 데모뿐만 아니라 감사 (audit)도 통과합니다.

*우리는 핀테크, 헬스케어 및 기타 고위험 (high-stakes) 도메인을 위한 프로덕션 AI를 구축하며, 단순히 데모에서 깊은 인상을 남기는 것이 아니라 컴플라이언스 검토 (compliance review)를 견뎌낼 수 있도록 설계합니다. 규제 대상 제품에 AI를 배포하고 있다면, 무엇이 유효한지에 대해 함께 논의해 봅시다