냉장고도 결제 기기다: 운영 환경의 금융 규정 RAG

• 원문 제목(original title): Your Fridge Is a Valid Payment Device — Eleonora Drykina & Nina Žižakić, In The Pocket
• Video ID: gonAewBZxfU
• URL: https://www.youtube.com/watch?v=gonAewBZxfU
• 채널: aiDotEngineer
• 발행일: 2026-10-14
• 발표 조직: 벨기에 디지털 제품 스튜디오 In The Pocket
• 발표자: Nina Žižakić(AI 엔지니어), Eleonora Drykina(제품 엔지니어)

20줄 핵심 요약

1. 벨기에 대형 결제 시스템의 규정은 약 270개 PDF, 6,000쪽, 약 3,000개 표에 흩어져 있다.

2. 규정집에는 휴대전화와 카드뿐 아니라 커프스 버튼, 핸드백, 의류, 냉장고도 결제 가능한 기기로 적혀 있다.

3. 금융 규정 RAG는 정확한 답변뿐 아니라 규정집의 섹션과 페이지를 함께 제시해야 한다.

4. 일반 상식은 모델 지식으로 보완할 수 있지만 수수료와 결제 방식은 규정집 근거 없이는 답하지 않아야 한다.

5. 오프라인 인덱싱은 PDF 추출, 청크 분할, 메타데이터 부착, 표 처리, 임베딩 생성으로 구성된다.

6. 문단을 약 2,000자 단위로 묶되 표가 청크 경계에서 잘리지 않게 하고 섹션 경로를 정규식으로 추적한다.

7. 청크를 겹치지 않게 유지하고 순서와 인덱스를 저장하면 섹션과 규정집을 원래 맥락으로 재구성할 수 있다.

8. 표의 병합된 행과 열을 그대로 텍스트화하면 수수료와 범위의 관계가 깨지므로 CSV로 변환해 필드를 복제한다.

9. 밀집 검색은 의미가 비슷한 문장을 찾고 BM25는 규정 코드와 정확한 식별자를 찾으므로 둘을 함께 사용한다.

10. Dense와 BM25 각각 상위 50개를 RRF로 합쳐 상위 30개로 줄이고 섹션 일관성 재정렬 후 10개를 에이전트에 전달한다.

11. 63개 검색 평가 질문에서 하이브리드 검색은 적중률을 92%에서 97%로 높였고 기존 Dense 적중 질문을 잃지 않았다.

12. 에이전트는 검색 결과, 전체 섹션, 전체 규정집, 사용 가능한 규정집 목록을 좁은 범위부터 넓은 범위로 탐색한다.

13. 10만 토큰이 넘는 규정집은 전체 내용을 주지 않고 섹션 목록을 반환하며, 잘못된 섹션명에도 재시도 가능한 목록을 돌려준다.

14. 여섯 번째 도구 호출 전 새로운 근거를 얻는지 되묻게 해 같은 검색을 반복하는 루프를 제한한다.

15. 답변 중앙값 지연시간은 38초이므로 Markdown 답변은 토큰 단위로 스트리밍하고 출처 카드는 별도 UI로 늦게 표시한다.

16. 질문, 도구 호출, 답변, 피드백, 출처 클릭, 답변 복사, 대화 기록을 Azure Table Storage에 기록하며 최근 20개 메시지만 보존한다.

17. 실제 소스 질문, 두 차례 사용자 테스트, 행동 지침, Promptfoo 86개 엔드투엔드 테스트, 검색·인용 검사를 함께 운영한다.

18. 자체 평가 변화 12건 중 5건은 재실행에서 재현되지 않았고 평가 루브릭이 실제 규정의 날짜를 환각으로 판정한 사례도 있었다.

19. 6월 내부 출시 뒤 약 900개 질문, 100개 이상 대화, 34명 사용자가 발생했고 3개월 차에는 질문의 90% 이상이 업무 관련이었다.

20. 구조 보존, 표 전용 처리, 다중 줌 레벨 검색, 스트리밍, 조기 사용자 테스트가 운영형 RAG의 핵심 설계 원칙으로 남았다.

📌 핵심 질문 / 운영형 금융 RAG가 해결해야 하는 문제

==규정집의 구조와 표 관계를 보존하면서 필요한 근거의 범위를 에이전트가 스스로 넓혀, 빠르게 확인 가능한 답변과 정확한 출처를 함께 제공할 수 있는가?==

• 고객의 결제 규정은 270여 개 PDF와 6,000쪽에 분산되어 있고 약 3,000개 표가 핵심 지식을 담고 있다.
• 규정집 사이에 상호 참조가 많아 검색 결과 상위 10개 청크만으로 답이 완성되지 않는 질문이 있다.
• 금융 답변은 규정집 섹션과 페이지로 검증되어야 하며, 일반 모델의 상식과 문서에 명시된 업무 규칙을 구분해야 한다.
• 답변 생성에 중앙값 38초가 걸리는 작은 연구 과제이므로 검색 품질뿐 아니라 진행 상황을 보여주는 UX도 시스템 품질의 일부가 된다.

냉장고처럼 예상 밖의 기기도 결제 수단으로 인정하는 한 줄짜리 규정은 표의 행·열 관계, 섹션 경로, 문서 간 참조를 함께 보존해야 찾아낼 수 있다. 따라서 단순한 벡터 검색-생성 파이프라인보다 재구성 가능한 인덱스, 하이브리드 검색, 다중 범위 도구, 검증 가능한 인용, 관찰 가능한 인터페이스가 필요하다.

1. 도메인 문제와 제품의 형태

1.1. 제목을 만든 규정의 의외성

1. 지루한 금융 문서 안의 뜻밖의 규칙

   1. 고객 규정집의 한 페이지에는 결제가 가능한 기기 목록이 있다.
   2. 휴대전화와 카드는 예상 가능한 항목이지만, 커프스 버튼·핸드백·의류·냉장고까지 목록에 포함된다.
   3. 평범하고 지루해 보이는 문서에서도 실제 제품 동작을 결정하는 흥미로운 사실이 나온다.

2. 발표자와 프로젝트 배경

   1. Nina Žižakić는 AI 엔지니어이고 Eleonora Drykina는 제품 엔지니어다.
   2. 두 사람은 벨기에 본사의 디지털 제품 스튜디오 In The Pocket에서 고객의 AI 전환과 맞춤형 소프트웨어 개발을 지원한다.
   3. 고객사는 벨기에의 대형 결제 시스템을 운영하지만 이름은 공개하지 않았다.

1.2. 규정 지식의 규모와 답변 조건

1. 문서의 규모와 연결성

   1. 규칙은 약 270개의 PDF 규정집에 기록되어 있으며 전체 분량은 약 6,000쪽이다.
   2. 약 3,000개의 표가 지식을 구조화하고, 중요한 정보가 일반 문장이 아니라 표 안에 들어 있다.
   3. 한 규정집이 다른 규정집을 참조하고 그 문서가 또 다른 문서를 참조하는 연쇄 구조가 있다.

2. 금융 답변에서의 출처와 근거

   1. 모든 답변은 정확해야 하고, 특히 금융 분야에서는 정확한 규정집 섹션과 페이지를 제시해야 사용자가 원문을 확인할 수 있다.
   2. 기반 LLM은 일반 지식을 알고 있으므로 은행의 의미처럼 상식적인 내용은 문서에 정의가 없어도 활용할 수 있다.
   3. 다른 결제 방식의 수수료나 작동 방식은 규정집에 명시되지 않았다면 일반 모델이 알고 있더라도 답변에 넣지 않아야 한다.

1.3. 사용자가 보는 규정 도우미

1. 챗봇 답변과 출처

   1. 사용자가 질문을 입력하면 규정집을 근거로 답변하고, 답이 표라면 표도 함께 보여준다.
   2. 답변 아래에 생성에 사용된 출처 목록을 배치하고, 각 출처의 섹션과 해당 부분을 표시한다.
   3. 사용자는 출처를 열어 PDF 원문을 확인할 수 있다.

2. 냉장고 질문과 후속 대화

   1. 대표 질문은 “냉장고로 결제할 수 있나요?”이다.
   2. 답변을 받은 뒤 사용자는 추가 질문을 이어갈 수 있다.
   3. 이 대화형 구조가 검색 결과 한 번을 보여주는 검색창과 구별되는 제품 경험을 만든다.

1.4. 오프라인 인덱싱과 온라인 서빙의 분리

1. 인덱싱 영역

   1. 새 규정집이 나올 때 PDF를 청크로 나누고 벡터 데이터베이스에 저장하는 오프라인 과정이다.
   2. 표 전용 처리와 메타데이터 부착을 거쳐 밀집 검색과 BM25 검색에 필요한 표현을 만든다.

2. 서빙 영역

   1. 사용자가 질문할 때 에이전트가 데이터베이스를 검색하고 필요한 범위의 문서를 가져온다.
   2. 답변과 출처가 실시간으로 사용자에게 전달된다.
   3. 인덱싱은 Nina가, 서빙은 Eleonora가 설명하는 방식으로 문제를 나눴다.

2. 인덱싱: 다시 조립할 수 있는 근거 만들기

2.1. PDF를 청크로 나누는 규칙

1. 문단 중심의 약 2,000자 청크

   1. PDF에서 텍스트를 추출한 뒤 문단 단위로 나눈다.
   2. 청크가 약 2,000자에 이를 때까지 문단을 담되, 표가 두 청크로 잘리지 않도록 경계를 조정한다.

2. 섹션 헤더 감지

   1. 정규 표현식으로 ‘제 3 장’이나 ‘4.2.1’ 같은 섹션 헤더를 찾아 현재 위치를 추적한다.
   2. 각 청크에 4장 4.2와 같은 섹션 경로를 부여한다.
   3. 섹션 경로는 인용에 표시할 위치이자 에이전트가 더 넓은 문맥을 불러올 때 사용하는 주소다.

3. 겹치지 않는 청크와 재구성

   1. 청크를 서로 겹치지 않게 만든다.
   2. 하나의 섹션을 청크들의 모음으로 보고, 청크 인덱스 순서대로 다시 배치하면 원래의 섹션을 복원한다.
   3. 이 설계가 검색된 한 문장을 넘어 일관된 섹션을 가져오는 기반이 된다.

2.2. 검색과 인용을 위한 메타데이터

1. 사용자에게 보여줄 출처 정보

   1. 모든 청크에 규정집 또는 안내서 이름과 페이지를 넣는다.
   2. 이 정보는 출처 카드에 표시되고 사용자가 PDF의 해당 내용으로 이동할 때 쓰인다.
   3. 섹션 경로는 인용의 정확한 위치를 설명하고, 에이전트가 전체 섹션을 한 번에 요청하게 한다.

2. 문서 재구성용 식별자

   1. 청크 인덱스를 저장해 섹션과 안내서 전체를 올바른 순서로 재구성한다.
   2. 안내서 ID로 전체 안내서 목록과 사용 가능한 항목을 확인할 수 있게 한다.
   3. 인덱싱 시점에 LLM으로 안내서 요약을 만들고 관련된 모든 청크에 붙여, 청크만 보아도 어느 문서에서 왔는지 알 수 있게 한다.

3. 업무 로직 필드

   1. 어떤 규정집인지, 어떤 규칙이 적용되는지, 표가 포함되어 있는지 등의 필드를 저장한다.
   2. 에이전트는 검색 결과와 함께 이 필드를 받아 다음 검색 범위와 답변 근거를 결정한다.

2.3. 표를 CSV로 보존하는 전용 처리

1. 일반 텍스트 추출의 실패

   1. 초기 방식은 PDF에서 일반 텍스트만 단순 추출했기 때문에 표의 구조가 유지되지 않았다.
   2. 예시 표에서 ‘국내’ 필드는 여러 행에 걸쳐 있고 ‘국경 간’도 두 행에 걸쳐 있으며 ‘환불’은 두 범위 모두에 걸쳐 있다.
   3. 병합 셀의 관계가 텍스트에서 사라지면 에이전트가 잘못된 수수료 행이나 열을 선택할 수 있다.

2. 필드 복제를 통한 관계 보존

   1. 표를 CSV로 변환하고 병합된 필드를 각 관련 행에 기본적으로 복제한다.
   2. 에이전트가 필요한 정보를 찾을 때 의미만 비슷한 행이 아니라 정확한 행을 식별할 수 있다.
   3. 수수료처럼 한 칸의 오독이 답변 전체를 틀리게 만드는 항목에서 정확도가 크게 달라진다.

3. 인덱싱 결과

   1. 인덱싱을 마치면 약 4,000개의 청크가 서빙 단계에 준비된다.
   2. 각 청크에는 텍스트, 위치, 재구성 정보, 문서 요약, 업무 로직 필드, 표 처리 결과가 함께 담긴다.

3. 서빙: 하이브리드 검색에서 에이전트 탐색으로

3.1. Dense와 BM25의 역할 분담

1. 밀집 임베딩의 강점과 약점

   1. 질문과 청크를 벡터로 바꾸어 거리를 비교하면 의미가 비슷한 표현과 의역을 잘 찾는다.
   2. 규정 코드, 메시지 이름, 정확한 식별자처럼 토큰 자체가 중요한 정보는 임베딩 모델에 노이즈처럼 보일 수 있다.

2. BM25의 보완 역할

   1. BM25는 정확한 토큰과 식별자를 잘 찾는다.
   2. 질문이 규정 문장을 의역하면 동일한 토큰이 없어져 BM25만으로는 놓칠 수 있다.
   3. 두 방식은 서로의 결함을 보완하는 검색 축이 된다.

3. RRF 기반 결합

   1. Dense 상위 50개와 BM25 상위 50개를 하나의 Quadrant 호출로 가져온다.
   2. 상호 순위 융합(RRF)으로 두 목록을 합쳐 상위 30개로 줄이고, 섹션 일관성을 위해 순위를 다시 조정한다.
   3. 최종 상위 10개 청크만 에이전트에 전달하므로 RRF 점수 자체를 두 검색 방식 사이에서 보정할 필요가 없다.

4. 검색 평가 결과

   1. 63개 질문으로 검색만 평가했을 때 Dense 단독 적중률은 92%였다.
   2. 하이브리드 방식은 적중률을 97%로 올렸다.
   3. Dense가 이미 찾을 수 있었던 질문을 하이브리드 결합이 새로 놓치지는 않았다.

3.2. 고정 파이프라인 대신 네 가지 도구를 쓰는 에이전트

1. 좁은 범위에서 넓은 범위로의 확대

   1. 첫 단계는 규정집 검색이며, 이전 단계에서 준비한 상위 10개 청크를 사용한다.
   2. 그 결과가 부족하면 섹션 경로를 기준으로 전체 섹션을 가져오는 ‘규정집 섹션 검색’을 호출한다.
   3. 더 넓은 질문에는 작은 규정집을 대상으로 ‘전체 규정집 검색’을 사용한다.
   4. 어떤 문서가 존재하는지 모를 때는 ‘사용 가능한 규정집 목록 조회’를 먼저 호출한다.

2. 문서 간 참조와 광범위한 질문

   1. 한 규정집이 다른 문서를 가리키는 질문은 상위 10개 청크의 포인터를 따라가야 답이 완성된다.
   2. 특정 거래 유형의 모든 수수료처럼 넓은 범위를 요구하는 질문은 상위 10개에 필요한 모든 항목이 들어갈 수 없다.
   3. 섹션과 규정집을 다시 구성할 수 있는 인덱스가 있어야 이런 질문에 단계적으로 대응할 수 있다.

3. 가드레일과 실패 회복

   1. 약 10만 토큰을 넘는 규정집에 전체 규정집 도구를 호출하면 본문을 컨텍스트에 넣지 않고, 너무 길다는 경고와 사용 가능한 섹션 목록을 돌려준다.
   2. 섹션 이름이 일치하지 않으면 유효한 섹션 목록을 반환해 에이전트가 포기하거나 이름을 지어내지 않고 재시도한다.
   3. 프롬프트의 ‘규율 지침’은 여섯 번째 호출 전에 새 정보를 얻는지, 실패한 검색을 다르게 표현하는 것인지 자문하게 한다.
   4. 실제 추적에서 원하는 결과가 언젠가 나오길 바라며 같은 검색을 반복하는 루프가 관찰되어 호출 제한을 도입했다.

3.3. 38초의 지연시간을 제품 동작으로 흡수하기

1. 검색 품질의 비용

   1. 대부분 질문은 두세 번에서 네 번의 도구 호출을 필요로 한다.
   2. 여러 도구와 재구성 과정의 비용으로 답변 중앙값 지연시간은 38초가 된다.
   3. 이 작업은 단순 채팅 응답이 아니라 작은 연구 과제에 가깝다.

2. 진행 중이라는 감각

   1. 38초 동안 화면이 멈춰 보이면 사용자는 시스템이 작동하지 않는다고 느낄 수 있다.
   2. 그래서 Markdown 답변을 토큰 단위로 스트리밍해 뭔가 진행되고 있다는 감각을 제공한다.
   3. 검색 범위를 넓히는 에이전트 설계와 스트리밍 UX가 지연시간을 서로 다른 층위에서 해결한다.

4. 구조화된 UI, 스트리밍, 관찰 가능성

4.1. Pydantic 객체의 장점과 스트리밍 한계

1. 첫 번째 UI 접근

   1. 기본 챗봇 화면을 벗어나기 위해 출처 카드, 이벤트, 접고 펼 수 있는 체크리스트 같은 UI 구성 요소를 준비했다.
   2. 구성 요소를 Pydantic 모델로 정의해 에이전트에 전달하고, 답변을 작성할 때 텍스트와 함께 선택하도록 했다.
   3. AI가 만든 UI가 단순 텍스트보다 읽기 쉬운 환경을 만들기를 기대했다.

2. 완성된 JSON을 기다려야 하는 문제

   1. Pydantic 객체는 일부만 스트리밍할 수 없고 마지막 토큰까지 도착해야 유효한 JSON이 된다.
   2. 답변에 38초가 걸리는 시스템에서 화면이 38초 동안 비어 있다가 모든 내용이 한꺼번에 나타났다.
   3. 구조화된 출력의 품질 이득이 대기 중 공백이라는 UX 손실로 바뀌었다.

3. Markdown과 출처 카드의 분리

   1. 에이전트가 Markdown 텍스트를 토큰 단위로 스트리밍하고 프론트엔드가 도착 즉시 스타일을 적용하게 했다.
   2. 출처 카드는 별도 UI 구성 요소로 분리해 답변 텍스트가 먼저 보인 뒤 추가한다.
   3. 출처 카드는 답변 전체를 읽기 전 반드시 클릭해야 하는 정보가 아니므로 지연 추가해도 손해가 없다.
   4. 단순 링크 대신 클릭 가능한 카드를 제공하면서 답변과 원문 검증의 연결도 개선됐다.

4.2. Azure Table Storage 기반 로깅

1. 기록 대상

   1. 질문, 도구 호출, 답변, 좋아요·싫어요 피드백을 기록한다.
   2. 출처 클릭, 답변 복사 같은 인터랙션과 전체 대화 기록도 기록한다.
   3. 사용자가 출처를 확인하는지, 답변을 복사하는지, 대화를 이어 가는지, 이탈하는지로 실제 경험을 관찰한다.

2. 작게 유지하는 맥락

   1. 현재 제품 단계에서는 Azure Table Storage에 최근 20개 메시지만 저장한다.
   2. 저장 맥락을 의도적으로 작게 유지해도 현재 제품 목적에는 충분하다.
   3. 제품이 성장하면 필요한 보존과 분석 기능을 다시 파악할 계획이다.

5. 평가: 검색 적중률을 넘어 실제 근거와 행동을 검증하기

5.1. 다층 평가 체계

1. 평가 재료

   1. 실제 규정 원문에서 추출한 평가 질문을 사용한다.
   2. 실제 사용자를 대상으로 두 차례 사용자 테스트를 진행한다.
   3. 조언하지 않기, 경쟁사에 중립적이기, 규칙에 없는 내용은 없다고 분명히 밝히기 같은 시스템 행동 지침을 둔다.

2. 자동화된 검증

   1. Promptfoo로 약 86개의 엔드투엔드 테스트를 운영한다.
   2. 전체 에이전트와 LLM 평가자를 루브릭에 대조하고, 올바른 원문 문서가 실제로 인용되었는지 별도 검사한다.
   3. 검색 전용 적중률 평가를 답변 품질 평가와 병행해 검색 실패와 생성·인용 실패를 구분한다.

5.2. LLM 평가자와 루브릭을 의심하는 법

1. 평가자 노이즈

   1. LLM 평가자에는 노이즈 하한선이 있어 한 번의 변화만으로 회귀를 신뢰할 수 없다.
   2. 자체 평가에서 관찰된 12번의 변동 중 5번은 재실행했을 때 재현되지 않았다.
   3. 변화를 제품 결론으로 삼기 전에 같은 조건에서 반복 실행해야 한다.

2. 루브릭 자체의 오류

   1. 평가자가 계속 환각이라고 지적한 날짜가 있었다.
   2. 원문을 직접 확인하자 그 날짜는 실제 규정서에 적혀 있는 사실이었다.
   3. 모델이 틀렸다는 자동 판정도 원문과 대조해야 하며, 평가 기준이 소스의 사실을 잘못 배제하는지 점검해야 한다.

6. 출시 후 사용과 실제 업무 정착

6.1. 초기 출시와 사용량

1. 출시 범위

   1. 규정서 도우미는 6월에 출시됐다.
   2. 초기에는 고객사 내부 사용자에게만 공개했다.
   3. 올해 말까지 외부 구성원과 고객에게도 공개하는 것이 목표다.

2. 관찰된 규모

   1. 지금까지 약 900개 질문이 들어왔다.
   2. 질문은 100개 이상의 대화로 나뉘었다.
   3. 실제 사용자는 약 34명이다.
   4. 좋아요·싫어요 피드백과 출처 클릭 수, 답변 복사 수를 수집했지만 대부분 사용자는 첫 달 이후 명시적 피드백 기능을 거의 쓰지 않았다.

6.2. 첫 달의 레드 팀과 세 달 차의 업무 질문

1. 초기 적대적 탐색

   1. 첫 달에는 사람들이 도우미를 무력화하려 하거나 주제에서 벗어난 질문을 던졌다.
   2. 사용자가 시스템 경계를 시험한 행동은 초기 레드 팀 활동처럼 나타났다.

2. 실제 업무로의 수렴

   1. 세 달 차에는 질문의 90% 이상이 실제 업무 관련 질문이었다.
   2. 사람들은 고객에게 받은 이메일을 붙여넣고 답변 작성을 요청했다.
   3. 실제 프로토콜 메시지나 표를 붙여넣고 검토받은 뒤 보낼 답장을 직접 작성하기도 했다.
   4. 시스템이 규정 검색 도구에서 업무 작성과 검토를 돕는 보조 도구로 확장된 셈이다.

3. 명시적 피드백이 적을 때의 감정 추론

   1. 좋아요·싫어요가 많지 않아 후속 질문의 흐름으로 상호작용의 감정을 해석했다.
   2. 사용자가 고맙다고 하거나 새 주제로 넘어가면 긍정적 상호작용으로 간주했다.
   3. 같은 내용을 다시 물으면 이전 답변이 충분하지 않았던 부정적 상호작용일 가능성이 있다고 보았다.
   4. 관찰 결과 대부분의 대화는 원활하게 진행됐다.

7. 프로젝트에서 얻은 설계 교훈

7.1. 문서와 인덱스

1. 구조 보존은 검색 이상의 문제다

   1. 섹션 구분은 올바른 답변을 검색하는 데 필요하다.
   2. 동시에 에이전트가 지식을 넓은 관점으로 이해하고 관련 청크를 순서대로 재구성하는 데도 필요하다.

2. 표는 별도 데이터 처리 대상이다

   1. 표의 병합된 행과 열을 일반 텍스트로 평탄화하면 관계가 사라진다.
   2. 표를 CSV로 가공하고 필드를 복제하는 전용 처리가 금융 답변의 정확도를 좌우한다.

7.2. 에이전트와 검색

1. 여러 줌 레벨 제공

   1. 가장 좁은 검색 결과부터 섹션, 규정집, 규정집 목록으로 확대하는 도구를 제공한다.
   2. 질문마다 필요한 맥락의 범위를 에이전트가 결정하게 하면 단일 호출의 고정 한계를 넘을 수 있다.

2. 단일 호출에서 에이전트형 검색으로의 전환

   1. 고정된 검색 후 생성 파이프라인에서 에이전트가 도구를 선택하는 방식으로 전환했다.
   2. 평가 수치가 상당히 상승했고, 문서 간 참조와 넓은 범위 질문을 처리할 여지가 커졌다.

7.3. UX와 검증

1. 스트리밍의 실용성

   1. 38초의 지연을 숨기는 스트리밍이 도구를 사용하기 좋게 만들었다.
   2. 구조화된 카드는 필요한 시점에만 추가해 텍스트 응답의 즉시성을 보존했다.

2. 조기 사용자 테스트의 역할

   1. 실제 사용자를 일찍 만나야 팀의 가정과 개선안이 실제 업무에서 효과가 있는지 알 수 있다.
   2. 사용자 인터뷰에서 얻은 질문과 행동을 평가 프롬프트로 만들고 제품 개선에 다시 사용한다.
   3. 자동 평가 결과도 원문과 사용자 행동에 대조해야 진짜 회귀와 평가 노이즈를 구분할 수 있다.

주요 발언 모음

“냉장고도 유효한 결제 수단이다.”

“38초라는 시간이 그냥 멈춰 있는 게 아니라 뭔가 실제로 진행되고 있다고 느끼게 하기 위해 스트리밍 방식을 활용합니다.”

“대부분의 질문은 2~4번의 호출이 필요하지만, 6번째 호출 전에는 정말 새로운 정보를 가져오는지 자문해야 합니다.”

“평가자가 잘못되었다고 지적한 날짜가 실제로 규칙서에 적혀 있던 텍스트였던 경우도 있었습니다.”

“구조화된 구성 요소는 UX상 꼭 필요할 때만 추가했습니다.”

핵심 데이터 & 수치

• 문서량: 약 270개 PDF, 약 6,000쪽.
• 표 수: 약 3,000개.
• 인덱싱 결과: 약 4,000개 청크.
• 검색 후보: Dense 상위 50개와 BM25 상위 50개를 결합해 상위 30개로 융합하고 최종 10개를 에이전트에 전달.
• 검색 평가: 63개 질문에서 Dense 단독 92%, 하이브리드 97% 적중률.
• 도구 호출: 일반적으로 질문당 2~4회, 6번째 호출 전 반복 검색 여부를 점검.
• 컨텍스트 가드레일: 약 10만 토큰을 넘는 규정집은 전체 본문 대신 섹션 목록을 반환.
• 답변 지연시간: 중앙값 38초.
• 로깅: 현재 대화의 최근 20개 메시지 보존.
• 평가 규모: Promptfoo 엔드투엔드 테스트 약 86개.
• 평가 신뢰성 사례: 12개 변동 중 5개가 재실행에서 재현되지 않음.
• 출시 후 사용량: 약 900개 질문, 100개 이상 대화, 약 34명 사용자.
• 업무 정착: 3개월 차 질문의 90% 이상이 실제 업무 관련.

결론 및 시사점

1. 규정·정책 RAG의 품질은 임베딩 모델 선택만으로 결정되지 않으며 문서의 섹션 계층, 페이지, 청크 순서, 표의 병합 관계를 보존하는 전처리에서 시작한다.
2. Dense 검색은 의미를, BM25는 정확한 규정 토큰을 담당하므로 두 검색 결과를 결합하면 한쪽의 강점을 잃지 않고 적중률을 높일 수 있다.
3. 검색 결과 10개를 무조건 컨텍스트에 넣는 대신 섹션과 전체 규정집으로 확대하는 도구를 에이전트에 주면 문서 간 참조와 광범위한 질문에 대응할 수 있다.
4. 도구 선택에는 토큰 제한, 유효 섹션 목록, 반복 검색 중단 지침을 넣어 컨텍스트 폭발과 근거 없는 이름 생성을 막아야 한다.
5. 중앙값 38초의 연구형 답변에서는 스트리밍과 출처 카드 분리가 검색 지연을 사용자 경험 손실로 바꾸지 않는 핵심 설계다.
6. LLM 평가자의 점수와 루브릭을 최종 판정으로 취급하지 말고 재실행, 원문 대조, 실제 사용자 테스트로 자동 평가를 반박할 수 있어야 한다.
7. 초기 레드 팀 질문이 세 달 뒤 업무 질문으로 수렴한 것처럼, 운영형 AI의 진짜 가치는 데모의 신기함보다 실제 이메일·프로토콜·표를 처리하는 반복 사용에서 확인된다.
8. 냉장고를 결제 기기로 인정하는 예시는 사소한 농담이 아니라, 기업 규정의 의미가 표와 문서 구조 속에 숨어 있으며 그 관계를 보존해야만 안전한 답을 만들 수 있다는 상징이다.