<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://beancount.io/ko/bean-labs/research-logs</id>
    <title>Beancount.io Blog</title>
    <updated>2026-07-12T00:00:00.000Z</updated>
    <generator>https://github.com/jpmonette/feed</generator>
    <link rel="alternate" href="https://beancount.io/ko/bean-labs/research-logs"/>
    <subtitle>Beancount.io Blog</subtitle>
    <icon>https://beancount.io/ko/img/favicon.png</icon>
    <entry>
        <title type="html"><![CDATA[FinRAGBench-V: 금융 도메인의 시각적 인용을 포함한 멀티모달 RAG]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/12/finragbench-v-multimodal-rag-visual-citation-financial-domain</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/12/finragbench-v-multimodal-rag-visual-citation-financial-domain"/>
        <updated>2026-07-12T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[FinRAGBench-V(EMNLP 2025)는 금융 분야에서 시각적 인용을 포함한 멀티모달 RAG를 위한 최초의 대규모 벤치마크로, 112,000페이지 이상의 문서와 1,394개의 사람이 주석을 단 질의응답 쌍을 포함합니다. 상위 모델들은 블록 수준 인용 재현율이 20~61%에 불과하며, 멀티모달 검색은 텍스트 전용 검색보다 거의 50% 포인트 더 높은 성능을 보입니다.]]></summary>
        <content type="html"><![CDATA[<p>금융 AI는 그동안 텍스트 전용 RAG가 주도해 왔지만, 실제 금융 문서는 OCR이 온전히 포착할 수 없는 차트, 표, 그림으로 가득 차 있습니다. FinRAGBench-V(EMNLP 2025)는 금융 도메인에서 시각적 인용을 포함한 멀티모달 RAG를 평가하는 최초의 대규모 벤치마크이며, 그 결과는 상용 시스템이 아직 갈 길이 멀다는 점을 일깨워줍니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-내용">논문 내용<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/12/finragbench-v-multimodal-rag-visual-citation-financial-domain#%EB%85%BC%EB%AC%B8-%EB%82%B4%EC%9A%A9" class="hash-link" aria-label="논문 내용에 대한 직접 링크" title="논문 내용에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=FinRAGBench-V%3A%20%EA%B8%88%EC%9C%B5%20%EB%8F%84%EB%A9%94%EC%9D%B8%EC%9D%98%20%EC%8B%9C%EA%B0%81%EC%A0%81%20%EC%9D%B8%EC%9A%A9%EC%9D%84%20%ED%8F%AC%ED%95%A8%ED%95%9C%20%EB%A9%80%ED%8B%B0%EB%AA%A8%EB%8B%AC%20RAG" alt="2026-07-12-finragbench-v-multimodal-rag-visual-citation-financial-domain" class="img_ev3q"></p>
<p>베이징 대학교의 Zhao, Jin, Li, Gao는 연구 보고서, 재무제표, 투자 설명서, 학술 논문, 잡지 및 뉴스 기사 등 실제 금융 문서로 구축된 이국어(Bilingual) 벤치마크인 FinRAGBench-V를 소개합니다. 검색 코퍼스는 상당한 규모로, 언어별로 약 1,100개의 문서에 걸쳐 중국어 60,780페이지와 영어 51,219페이지로 구성되어 있습니다. 또한 텍스트 추론, 차트 및 표 추출, 수치 계산, 시간 민감형 쿼리, 다중 페이지 추론 등 7가지 질문 범주에 걸친 1,394개의 인간 주석 QA 쌍이 포함됩니다. 데이터셋 외에도 이 논문의 핵심 기여는 RGenCite라는 베이스라인 시스템입니다. 이 시스템은 각 주장을 뒷받침하는 특정 문서 영역을 표시하는 바운딩 박스 좌표 형태의 픽셀 수준 시각적 인용과 함께 답변을 생성합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-개념">주요 개념<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/12/finragbench-v-multimodal-rag-visual-citation-financial-domain#%EC%A3%BC%EC%9A%94-%EA%B0%9C%EB%85%90" class="hash-link" aria-label="주요 개념에 대한 직접 링크" title="주요 개념에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>멀티모달 검색이 텍스트 전용 검색을 압도적인 차이로 제압</strong>: 페이지 이미지 임베딩을 기반으로 구축된 시각-언어 검색 모델인 ColQwen2는 Recall@10에서 90.13%(중국어) 및 85.86%(영어)를 달성했습니다. 반면 가장 뛰어난 텍스트 기반 검색 모델인 BM25와 BGE-M3는 약 42.71%에 머물렀습니다. 이 격차는 단순한 오차가 아닙니다.</li>
<li class=""><strong>최첨단 모델에서도 생성 정확도가 낮음</strong>: 영어의 경우 GPT-4o는 43.41%의 정확도(ROUGE 24.66)를 기록했고, 중국어의 경우 o4-mini는 58.13%(ROUGE 38.55)를 기록했습니다. 이들은 강력한 검색 기능을 갖춘 최상위 상용 모델들입니다.</li>
<li class=""><strong>페이지 수준 인용은 작동하지만, 블록 수준은 그렇지 않음</strong>: 최고 모델들의 페이지 수준 재현율은 75<del>93%에 달합니다. 하지만 특정 표 셀이나 차트 영역이 주장의 근거임을 파악하는 블록 수준 재현율은 20</del>61%로 급감합니다. 이는 감사 가능성(Auditability) 측면에서 핵심적인 공백입니다.</li>
<li class=""><strong>수치 추론 및 다중 페이지 추론이 모델의 성능을 가장 먼저 저하시킴</strong>: 여러 페이지나 시간 범위에 걸친 계산이 필요한 질문에서 모든 테스트 시스템의 정확도가 가장 가파르게 떨어졌습니다.</li>
<li class=""><strong>상용 모델이 오픈 소스 대안보다 실질적으로 우수한 성능을 보임</strong>: 여기서는 대부분의 NLP 벤치마크보다 폐쇄형 API와 오픈 소스 간의 격차가 더 크게 나타나며, 이는 오픈 모델들에게 시각적 금융 추론이 여전히 해결되지 않은 과제임을 시사합니다.</li>
<li class=""><strong>인용에 대한 자동 평가는 불완전함</strong>: 이미지 크로핑 기반의 인용 평가기는 인간의 판단과 Pearson r = 0.68의 상관관계를 보였는데, 이는 합리적이지만 샘플링 없이 완전히 신뢰하기에는 부족한 수준입니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/12/finragbench-v-multimodal-rag-visual-citation-financial-domain#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>검색 결과는 이 논문에서 가장 신뢰할 수 있는 부분입니다. 60,000페이지 이상의 규모에서 멀티모달 검색 모델과 텍스트 전용 검색 모델 사이에 거의 50% 포인트의 격차가 난다는 것은 간과하기 힘든 결과입니다. 인덱싱 전에 금융 문서를 OCR로 변환하면 숫자가 어느 열에 있는지, 그림 캡션이 표의 해석을 어떻게 바꾸는지와 같은 구조적 레이아웃 신호가 파괴되는데, 이러한 정보가 검색에 매우 중요하다는 것이 입증되었습니다.</p>
<p>생성 관련 수치는 정직하지만 단독으로 해석하기는 어렵습니다. 저자들은 정확도 격차 중 어느 정도가 검색 오류에 의한 것이고 어느 정도가 생성 실패에 의한 것인지 분리하여 분석하지 않았습니다. Recall@10이 영어에서 이미 85.86%라는 점을 감안하면, 상당 부분의 실패는 검색보다는 생성 측면에서 발생했을 것입니다. 이러한 세부 분석이 있었다면 병목 현상이 멀티모달 추론 때문인지, 아니면 MLLM이 금융 언어를 처리하는 방식의 더 근본적인 문제인지 명확해졌을 것입니다.</p>
<p>1,394개의 QA 쌍으로 구성된 평가 세트는 벤치마크 범위에 비해 적은 편입니다. 7가지 범주와 2개 언어로 나눌 경우, 일부 섹션은 예시가 200개 미만입니다. 범주별 결과의 통계적 유의성은 암시적으로만 남아 있습니다. 벤치마크 논문에서 흔히 있는 일이지만, 이는 유리한 비교 데이터를 구성하기 쉬울 수도 있음을 의미합니다.</p>
<p>인용 평가 프로토콜은 흥미로운 기여이지만, 인간 평가와의 상관관계(Pearson r = 0.68)는 자동 평가를 블록 수준 근거 탐색의 절대적 기준으로 삼기에는 충분히 강력하지 않습니다. 저자들도 이를 인정하고 있으며, 더 나은 인용 지표에 대한 향후 연구의 필요성을 명시적으로 언급했습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에-이것이-중요한-이유">금융 AI에 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/12/finragbench-v-multimodal-rag-visual-citation-financial-domain#%EA%B8%88%EC%9C%B5-ai%EC%97%90-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>Beancount는 평문(plain-text) 원장 파일에서 작동하므로 과거 거래를 조회할 때 텍스트 전용 RAG를 사용하는 것이 타당해 보일 수 있습니다. 하지만 더 넓은 범위의 회계 작업에는 은행 거래 내역 PDF, 스캔된 송장, 영수증 이미지, 표와 차트가 포함된 연례 보고서 등 평문이 아닌 문서들이 반드시 포함됩니다. Beancount 에이전트가 원장 항목을 소스 문서와 대조하여 조정(Reconciliation)해야 하는 순간—즉, 특정 비용이 보관된 송장과 일치하는지 확인하는 작업—이 바로 FinRAGBench-V가 벤치마킹하는 작업입니다.</p>
<p>블록 수준 인용 결과는 이 사용 사례에서 가장 중요합니다. 에이전트가 PDF의 특정 라인 항목을 가리켜 원장 기입을 정당화해야 하는데, 현재 최고 수준의 시스템도 블록 수준 재현율이 20~61%에 불과하다면 이는 감사에 바로 사용할 수 있는 수준이 아닙니다. 스캔된 소스 문서를 다루는 모든 Beancount 파이프라인은 이 수치가 실질적으로 개선될 때까지 인간의 검토(Human-in-the-loop)가 필요합니다.</p>
<p>검색 방식의 격차 또한 문서 수집 단계에서 순수 텍스트 파이프라인을 지양해야 함을 강력하게 시사합니다. 영수증 이미지에는 금액 필드, 업체명, 라인 항목 위치와 같은 레이아웃 정보가 포함되어 있으며, OCR은 이를 파괴합니다. 이러한 레이아웃 정보는 항목 합계와 세액을 구분하는 결정적인 요소이며, FinRAGBench-V는 멀티모달 검색 모델이 텍스트 검색 모델은 할 수 없는 방식으로 이를 활용함을 보여줍니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어볼-거리">더 읽어볼 거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/12/finragbench-v-multimodal-rag-visual-citation-financial-domain#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%BC-%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="더 읽어볼 거리에 대한 직접 링크" title="더 읽어볼 거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>ColPali: Efficient Document Retrieval with Vision Language Models</strong> — FinRAGBench-V의 최고 검색 모델이 기반으로 삼은 시각적 페이지 임베딩 방식을 정립한 ColQwen2의 전신 [arXiv:2407.01449, ECCV 2024]</li>
<li class=""><strong>M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding</strong> — 여러 페이지와 문서에 걸친 단일 및 다중 홉(multi-hop) 시각적 추론을 처리하는 유연한 프레임워크로 다중 문서 시각적 QA를 해결함 [arXiv:2411.04952]</li>
<li class=""><strong>Benchmarking Temporal-Aware Multi-Modal RAG in Finance</strong> — 금융 멀티모달 RAG의 시간 민감성을 평가하는 2025년의 동반 벤치마크로, FinRAGBench-V의 시간 민감형 질문 범주를 직접적으로 보완함 [arXiv:2503.05185]</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Finance" term="Finance"/>
        <category label="Financial Reporting" term="Financial Reporting"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Reconciliation" term="Reconciliation"/>
        <category label="Beancount" term="Beancount"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[LLM 에이전트가 CFO가 될 수 있을까? EnterpriseArena의 132개월 시뮬레이션이 보여주는 거대한 격차]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/11/can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/11/can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark"/>
        <updated>2026-07-11T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[EnterpriseArena는 생존율, 최종 가치, 결산율을 추적하며 11개의 LLM을 대상으로 132개월간의 CFO 시뮬레이션을 수행했습니다. 오직 Qwen3.5-9B만이 80%의 실행에서 생존했으며, GPT-5.4와 DeepSeek-V3.1은 0%를 기록했습니다. 인간 전문가는 100% 생존율과 최종 가치 5배를 달성했습니다. 결정적인 병목 현상은 LLM이 80%의 경우 장부 대조를 건너뛰고 오래된 재무 상태를 바탕으로 행동한다는 점이었습니다.]]></summary>
        <content type="html"><![CDATA[<p>현재 금융 AI 분야에서 가장 야심 찬 질문은 "LLM이 대차대조표에 관한 질문에 답할 수 있는가?"가 아니라 "LLM이 자금이 고갈되지 않게 유지하면서 장기간 회사의 자금을 관리할 수 있는가?"입니다. Yi Han 등의 논문 <em>Can LLM Agents Be CFOs?</em> (arXiv:2603.23638)는 이를 정확히 테스트하기 위해 EnterpriseArena를 구축했으며, 그 답은 '간신히, 그리고 예상과는 다른 방식으로'였습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-소개">논문 소개<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/11/can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark#%EB%85%BC%EB%AC%B8-%EC%86%8C%EA%B0%9C" class="hash-link" aria-label="논문 소개에 대한 직접 링크" title="논문 소개에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=LLM%20%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8%EA%B0%80%20CFO%EA%B0%80%20%EB%90%A0%20%EC%88%98%20%EC%9D%88%EC%9D%84%EA%B9%8C%3F%20EnterpriseArena%EC%9D%98%20132%EA%B0%9C%EC%9B%94%20%EC%8B%9C%EB%AE%AC%EB%A0%88%EC%9D%B4%EC%85%98%EC%9D%B4%20%EB%B3%B4%EC%97%AC%EC%A3%BC%EB%8A%94%20%EA%B1%B0%EB%8C%80%ED%95%9C%20%EA%B2%A9%EC%B0%A8" alt="2026-07-11-can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark" class="img_ev3q"></p>
<p>EnterpriseArena는 CFO 수준의 자원 배분을 시뮬레이션하는 132개월(11년) 과정의 테스트입니다. 각 타임스텝은 1개월을 나타냅니다. 에이전트는 기업 수준의 재무 정보, 익명화된 비즈니스 문서, 그리고 FRED, CBOE, S&amp;P Global 데이터에서 추출한 거시 경제 신호를 부분적으로 관찰합니다. 에이전트에게는 현금 보유고 확인, 재무 기록 검토, 시장 상황 분석, 현금 흐름 투영이라는 네 가지 작업에 걸쳐 매달 20번의 도구 호출 예산이 주어집니다. 에이전트는 장부 마감(대조), 자금 요청(지분 또는 부채, 확률적 결과 수반), 또는 대기 중 하나를 선택해야 합니다. 주요 제약 조건은 회사의 현금 잔고가 모든 타임스텝에서 0 이상을 유지해야 한다는 것입니다. 이를 위반하면 해당 에피소드는 종료되며 0점을 받습니다. 생존할 경우, 에이전트는 Rev_T × 5 + Cash_T − 5,000 × N_tools라는 공식에 따라 최종 기업 가치를 극대화해야 하며, 이 공식은 과도한 도구 사용에 명시적으로 벌점을 부여합니다.</p>
<p>평가에는 Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B, Qwen3.5-9B를 포함한 11개의 LLM이 사용되었으며, 각각 8년과 14년의 경력을 가진 두 명의 재무 전문가가 검증한 인간 전문가 기준치와 비교되었습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-요점">주요 요점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/11/can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark#%EC%A3%BC%EC%9A%94-%EC%9A%94%EC%A0%90" class="hash-link" aria-label="주요 요점에 대한 직접 링크" title="주요 요점에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>모델 간 생존율의 극심한 차이</strong>: Qwen3.5-9B는 실행의 80%에서 생존했고, Gemini-3.1-Pro는 50%, Claude-Haiku-4.5와 GLM-5는 각각 20%를 기록했습니다. 반면 GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B, Mixtral-8x7B는 모두 0%의 생존율을 보였습니다. LLM의 전체 평균 생존율은 26%입니다.</li>
<li class=""><strong>거대 모델이 소형 모델보다 항상 우수한 것은 아님</strong>: Qwen3.5-9B(매개변수 90억 개, 생존율 80%, 최종 가치 7,880만 달러)는 Qwen3.5-397B(매개변수 3,970억 개, 생존율 20%)와 GPT-5.4(생존율 0%)를 압도했습니다.</li>
<li class=""><strong>인간과의 거대한 격차</strong>: 인간 기준치는 100% 생존율과 1억 5,220만 달러(±2,960만 달러)의 최종 가치를 달성했습니다. LLM 평균은 생존율 26%에 2,820만 달러에 불과했습니다.</li>
<li class=""><strong>결산이 결정적인 병목 현상</strong>: 인간 전문가는 타임스텝의 94.3%에서 장부를 마감(대조)하지만, LLM은 평균 19.3%에 그쳤습니다. 결산은 실제 재무 제표를 생성하고 이후의 합리적인 결정을 가능하게 하는 핵심 작업입니다.</li>
<li class=""><strong>행동 없는 정보 수집은 치명적</strong>: Qwen3.5-397B는 시뮬레이션 내내 시장 분석 및 예측 도구를 높은 비율로 사용했지만, 장부 마감은 거의 하지 않았으며(결산율 0.0%) 자금 요청도 거의 하지 않아 상황을 '알고 있음'에도 불구하고 현금 고갈로 파산했습니다.</li>
<li class=""><strong>도구 예산 벌점의 중요성</strong>: 채점 공식은 행동하기보다 강박적으로 확인만 하는 에이전트에게 벌점을 부여하며, 이는 실제 기회 비용을 반영하는 제약 조건입니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/11/can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>생존을 엄격한 제약 조건으로 두고 최종 가치를 목표로 하는 이중 목적 설계는 최근 에이전트 벤치마킹에서 가장 뛰어난 선택 중 하나입니다. 이는 실제 CFO가 운영되는 방식, 즉 돈이 떨어지면 성장을 최적화할 수 없다는 현실을 반영합니다. 날짜와 회사명을 익명화한 것은 모델이 암기된 과거 결과에 패턴 매칭을 하는 것을 방지하며, 이는 실제 티커와 날짜를 사용하는 기존 금융 벤치마크보다 개선된 방법론입니다.</p>
<p>저자들이 사례 연구를 통해 식별한 실패 모드 분류는 설득력이 있습니다. GPT-5.4는 99.1%의 통과율을 기록했지만(거의 모든 타임스텝에서 아무것도 하지 않음으로써 행동을 취함), Qwen3.5-397B는 분석을 행동으로 착각했습니다. 이는 서로 다른 해결책이 필요한 행동적 실패 모드들입니다.</p>
<p>덜 설득력 있는 부분은 가우시안 노이즈를 사용하여 시장 충격을 근사화한 확률적 거시 환경입니다. 저자들도 인정했듯이, 이는 블랙 스완 이벤트나 인간의 비합리성을 재현할 수 없습니다. 또한 매월 20회의 도구 호출 예산은 다소 임의적입니다. 실제 CFO는 자신의 기억에 대해 이러한 쿼리 속도 제약을 받지 않으므로, 이 벤치마크가 장기적인 재무 판단력을 측정하는 것인지 아니면 자원 압박 하의 RAG(검색 증강 생성) 능력을 측정하는 것인지 의문이 남습니다. 저자들이 언급한 단일 에이전트 구조 또한 한계점입니다. 실제 CFO는 컨트롤러, FP&amp;A 분석가, 재무팀으로 구성된 계층 구조 내에서 운영되지만, 이 논문은 이를 시뮬레이션하지 않았습니다.</p>
<p>모델 크기가 생존율을 예측하지 못한다는 발견은 놀랍고 아마 사실일 것이지만, 그 메커니즘은 충분히 설명되지 않았습니다. 저자들은 이것이 지시 이행 능력의 실패인지, 긴 문맥의 일관성 문제인지, 아니면 리스크 보정의 문제인지를 명확히 분석하지 않고 단순히 현상만 기록했습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에-주는-시사점">금융 AI에 주는 시사점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/11/can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark#%EA%B8%88%EC%9C%B5-ai%EC%97%90-%EC%A3%BC%EB%8A%94-%EC%8B%9C%EC%82%AC%EC%A0%90" class="hash-link" aria-label="금융 AI에 주는 시사점에 대한 직접 링��크" title="금융 AI에 주는 시사점에 대한 직접 링크" translate="no">​</a></h2>
<p>EnterpriseArena의 장부 마감 작업은 본질적으로 Beancount의 <code>balance</code> 어설션(assertion) 및 원장 대조 단계와 같습니다. 즉, 행동하기 전에 재무 상태의 실제 데이터(ground-truth)를 확정하는 순간입니다. LLM이 이를 80%나 건너뛴다는 발견은 '쓰기 복구(write-back) 안전성' 문제와 직결됩니다. 행동하기 전 대조를 피하는 에이전트는 오래되었거나 환각된 상태를 바탕으로 행동하는 에이전트입니다. Beancount 자동화의 경우, 에이전트 루프에서 대조 단계는 선택 사항이 아닌 필수적이고 검증 가능한 단계여야 함을 시사합니다.</p>
<p>132개월의 기간은 수년간의 원장 관리와 직접적으로 유사합니다. 시간이 지남에 따라 지속적인 상황 인지 능력이 저하된다는 발견은 5년 치 거래 내역을 관리하는 Beancount 에이전트에서도 예상할 수 있는 퇴보입니다. 에이전트가 문맥 내에 모든 데이터를 가지고 있더라도 60개월 차에 일관성 있게 행동하지 못할 수 있습니다. 이는 장기 실행되는 Beancount 에이전트 세션에서 사후적인 쿼리뿐만 아니라 주기적인 강제 대조 체크포인트가 필요함을 시사합니다.</p>
<p>Qwen3.5-397B가 빠진 '정보 수집의 늪'은 유용한 설계 경고입니다. 많은 검색 도구를 갖춘 에이전트는 특히 잘못된 행동(원장 오염)의 비용이 높을 때 결정을 내리기보다 검색을 선호할 수 있습니다. EnterpriseArena에서 사용된 것과 같은 도구 호출 예산 제약은 Beancount 쓰기 에이전트에서 행동의 규율을 강제하는 데 도움이 될 수 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어보기">더 읽어보기<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/11/can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%B4%EA%B8%B0" class="hash-link" aria-label="더 읽어보기에 대한 직접 링크" title="더 읽어보기에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>EcoGym</strong> (arXiv:2602.09514) — 자판기, 프리랜서, 운영 환경에서 1,000단계 이상 진행되는 보완적인 장기 경제 벤치마크입니다. 세 환경 모두에서 압도적인 모델이 없다는 점은 EnterpriseArena의 실패 모드가 특정 벤치마크 설계의 특이점이 아님을 시사합니다.</li>
<li class=""><strong>AFlow: Automating Agentic Workflow Generation</strong> (arXiv:2410.10762, ICLR 2025 oral) — 워크플로우 설계를 MCTS와 LLM 피드백을 통한 코드 공간 검색으로 재구성합니다. EnterpriseArena가 수동으로 설계된 에이전트 행동의 실패를 보여준다면, AFlow는 더 나은 파이프라인을 자동으로 발견하기 위한 다음 단계입니다.</li>
<li class=""><strong>ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs</strong> (arXiv:2307.16789, ICLR 2024) — 기초적인 도구 사용 학습 및 평가 프레임워크입니다. ToolLLM에서 도구 호출 행동이 어떻게 학습되는지 이해하면 EnterpriseArena의 행동 회피 실패가 학습의 문제인지 프롬프팅의 문제인지 명확해질 것입니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Automation" term="Automation"/>
        <category label="Reconciliation" term="Reconciliation"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Cash Flow" term="Cash Flow"/>
        <category label="Financial Management" term="Financial Management"/>
        <category label="Forecasting" term="Forecasting"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[WildToolBench: 실제 환경의 도구 사용에서 LLM의 세션 정확도가 15%를 넘지 못하는 이유]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/10/wildtoolbench-benchmarking-llm-tool-use-in-the-wild</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/10/wildtoolbench-benchmarking-llm-tool-use-in-the-wild"/>
        <updated>2026-07-10T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[WildToolBench(ICLR 2026)는 실제 사용자 행동에서 추출된 1,024개의 작업에 대해 57개의 LLM을 평가합니다. 그 결과 세션 정확도가 15%를 넘는 모델은 없었으며, 구성적 오케스트레이션, 숨겨진 의도, 지시어 전환이 세 가지 주요 실패 유형으로 나타났습니다.]]></summary>
        <content type="html"><![CDATA[<p>제가 추적해 온 BFCL, ToolBench, τ-bench와 같은 도구 사용(tool-use) 벤치마크들은 모두 공통적인 설계 결함을 공유하고 있습니다. 바로 벤치마크 저자들이 상상한 사용자의 행동을 바탕으로 과제를 구성한다는 점입니다. ICLR 2026에 채택된 WildToolBench는 실제 사용자 로그로 돌아가 사용자들이 <em>실제로</em> 무엇을 하는지 묻습니다. 그 대답은 겸허한 결과를 보여줍니다. 57개의 LLM을 평가한 결과, 세션 정확도가 15%를 초과하는 모델은 하나도 없었습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-요약">논문 요약<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/10/wildtoolbench-benchmarking-llm-tool-use-in-the-wild#%EB%85%BC%EB%AC%B8-%EC%9A%94%EC%95%BD" class="hash-link" aria-label="논문 요약에 대한 직접 링크" title="논문 요약에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=WildToolBench%3A%20%EC%8B%A4%EC%A0%9C%20%ED%99%98%EA%B2%BD%EC%9D%98%20%EB%8F%84%EA%B5%AC%20%EC%82%AC%EC%9A%A9%EC%97%90%EC%84%9C%20LLM%EC%9D%98%20%EC%84%B8%EC%85%98%20%EC%A0%95%ED%99%95%EB%8F%84%EA%B0%80%2015%25%EB%A5%BC%20%EB%84%98%EC%A7%80%20%EB%AA%BB%ED%95%98%EB%8A%94%20%EC%9D%B4%EC%9C%A0" alt="2026-07-10-wildtoolbench-benchmarking-llm-tool-use-in-the-wild" class="img_ev3q"></p>
<p>알리바바의 Peijie Yu, Wei Liu, Yifan Yang 및 동료들은 실제 사용자 행동 패턴에서 추출되고 약 1,600개의 공용 API를 기반으로 한 1,024개의 작업과 256개의 멀티턴 대화 시나리오로 구성된 벤치마크인 WildToolBench(arXiv:2604.06185)를 발표했습니다. 핵심 주장은 기존 벤치마크의 성능이 포화 상태에 이른 이유가 모델이 우수해서가 아니라 작업이 인위적이기 때문이라는 것입니다. 실제 사용자는 요청을 한데 묶어서 보내고, 두 턴 전에 공유한 맥락을 생략하며, 때로는 단일 메시지 내에서도 도구 관련 질문, 가벼운 대화, 설명 요청 사이를 전환합니다. WildToolBench는 이러한 실패 모드를 세 가지 구조화된 챌린지 카테고리로 구체화하고, 작업 수준의 정확도와 대화 내의 4개 작업을 모두 성공해야 하는 훨씬 더 엄격한 세션 수준 정확도를 측정합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-내용">주요 내용<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/10/wildtoolbench-benchmarking-llm-tool-use-in-the-wild#%EC%A3%BC%EC%9A%94-%EB%82%B4%EC%9A%A9" class="hash-link" aria-label="주요 내용에 대한 직접 링크" title="주요 내용에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>대부분의 모델에서 세션 정확도가 한 자릿수로 급락</strong>: Gemini-2.0-Flash-Thinking이 14.45%의 세션 정확도로 선두를 달리고 있으며, Claude-4-Sonnet은 12.50%, GPT-4o는 11.72%를 기록했습니다. 4턴 세션의 모든 작업을 통과하는 것은 매우 어렵기 때문에 60%의 작업 정확도조차 15% 미만의 세션 정확도로 이어집니다. 이는 모든 상호작용에 부과되는 복합 확률 세금과 같습니다.</li>
<li class=""><strong>구성적 오케스트레이션(Compositional orchestration)이 가장 큰 난관</strong>: 순차적 방식과 병렬 방식이 혼합된 도구 토폴로지는 상위 모델의 작업 정확도를 25%로 제한하는 반면, 순수 병렬 또는 순차 체인에서는 54~62%의 정확도를 보였습니다. 작업에 병렬 확장 후 순차 통합이 필요한 경우, 조정(coordination) 문제는 현재 어떤 모델도 안정적으로 처리할 수 있는 수준을 넘어섭니다.</li>
<li class=""><strong>숨겨진 의도(Hidden intent)는 이전에 측정한 것보다 더 큰 격차를 보임</strong>: WildToolBench는 작업의 100%에 암시적 또는 턴을 교차하는 정보가 포함되도록 보장하는 반면, BFCL v3는 15.7%에 불과합니다. 누락된 정보가 두 턴 이상 뒤에 있는 장기 의존성 작업은 가장 어려운 하위 유형으로, 작업 수준에서도 50%를 넘는 모델이 없었습니다.</li>
<li class=""><strong>지시어 전환(Instruction transitions)은 선형적으로 오류를 가중시킴</strong>: 정책 전환(도구 작업 → 채팅 → 확인 → 도구 작업)이 추가될 때마다 정확도가 약 5~15%포인트씩 떨어집니다. 세 번의 전환이 발생하면 가장 큰 영향을 받는 모델은 30포인트의 성능 하락을 보입니다. 저자들은 이를 "자기 조건화(self-conditioning)"라고 부르는데, 이전의 응답이 이후 지시어에 대한 모델의 해석에 편향을 주어 세션 도중에 수정하기 어렵게 만드는 현상을 의미합니다.</li>
<li class=""><strong>최적 경로 비율(Optimal Path Rate)은 43% 미만</strong>: 모델이 작업을 올바르게 완료하더라도 불필요하게 많은 API 호출을 소모합니다. Claude-4-Sonnet은 42.74%로 가장 우수한 최적 경로 비율을 기록했는데, 이는 올바른 결과물 중 과반수가 필요 이상의 단계를 거쳤음을 의미하며, 이는 실제 운영 시스템에서 지연 시간과 토큰 비용으로 직결됩니다.</li>
<li class=""><strong>특화된 도구 사용 모델이 범용 프론티어 모델보다 성능이 낮음</strong>: xLAM-2-70B와 ToolACE2-8B는 모두 잘못된 함수 이름을 호출하는 오류율이 30%를 초과하여 GPT-4o나 Claude-4-Sonnet보다 나쁜 성적을 거두었습니다. 좁은 범위의 도구 사용 말뭉치로 파인튜닝하는 것은 실제 사용자의 무작위적인 행동(wild behavior)으로 인한 분포 변화(distribution shift) 상황에서 견고함보다는 취약함을 만드는 것으로 보입니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-한계점">유효한 점과 한계점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/10/wildtoolbench-benchmarking-llm-tool-use-in-the-wild#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%ED%95%9C%EA%B3%84%EC%A0%90" class="hash-link" aria-label="유효한 점과 한계점에 대한 직접 링크" title="유효한 점과 한계점에 대한 직접 링크" translate="no">​</a></h2>
<p>이 벤치마크 설계는 가장 중요한 지점에서 강력한 설득력을 갖습니다. 작업 정확도와 세션 정확도를 구분한 것은 매우 정확한 접근입니다. 복합적인 실패 유형이야말로 실제 배포 환경을 망치는 주범이며, 이전의 연구들은 이를 가리는 작업 수준의 수치만을 보고해 왔습니다. 세 가지 챌린지 분류(구성적 오케스트레이션, 숨겨진 의도, 지시어 전환)는 타당한 근거를 갖추고 있으며 실증적으로 입증되었습니다. 각 챌린지 유형에 따른 성능 저하 곡선은 실제적이고 인상적입니다.</p>
<p>약점은 규모입니다. 256개 시나리오에서 추출한 1,024개의 작업은 연구 결과물로서는 신뢰할 수 있지만, 시간이 지남에 따라 57개의 모델을 추적하려는 리더보드용으로는 부족해 보입니다. 저자들도 이 점을 직접 인정하며 향후 연구에서 자동화된 확장 파이프라인을 언급했습니다. 또 다른 문제는 "실제 사용자 로그 기반"이라는 표현이 상당히 가공되었다는 점입니다. 최종 작업은 시드 패턴에서 멀티 에이전트 시스템에 의해 부분적으로 합성되어 생성된 후 인간 어노테이터에 의해 검증되었습니다. 즉, 데이터가 실제 환경에서 그대로 가져온 것이 아니라 실제 환경에서 <em>영감을 받은</em> 것입니다. 이는 15%라는 천장을 얼마나 문자 그대로 해석해야 하는지에 영향을 미칩니다. 생성 파이프라인이 실제 사용자가 보이지 않는 인위적인 난이도를 도입했다면 격차의 일부는 줄어들 수 있습니다.</p>
<p>또한 지시어 전환 분석을 아키텍처 측면의 한계로 보는 주장에도 회의적입니다. 논문은 이를 근본적인 한계로 돌리지만, RLHF 파인튜닝 목표와 멀티모달 사용자 세션 간의 학습 분포 불일치가 더 타당한 설명일 수 있습니다. 이는 구조적인 문제가 아니라 해결 가능한 문제입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-aifinance-ai에-중요한-이유">금융 AI(Finance AI)에 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/10/wildtoolbench-benchmarking-llm-tool-use-in-the-wild#%EA%B8%88%EC%9C%B5-aifinance-ai%EC%97%90-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI(Finance AI)에 중요한 이유에 대한 직접 링크" title="금융 AI(Finance AI)에 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>이 세 가지 실패 유형은 실제 사용자가 Beancount 쓰기 작업(write-back) 에이전트와 상호작용하는 방식과 거의 완벽하게 일치합니다. 사용자가 "지난달 식비로 얼마 썼지? 그리고 하는 김에 오늘 Whole Foods 영수증도 추가해줘"라고 묻는다면, 이는 한 턴에 묶인 구성적 작업입니다. 이어서 "방금 그거 42달러가 아니라 47.23달러로 수정해줘, 방금 확인했어"라고 말한다면, 이는 에이전트가 세션 상태를 추적해야 하는 매개변수 수정 작업입니다. 그런 다음 "그 카테고리가 맞아?"라고 묻는다면 이는 설명 요청이며, 에이전트는 방금 완료한 쓰기 작업을 다시 실행해서는 안 됩니다. 혼합 순차+병렬 오케스트레이션에서의 25% 한계와 지시어 전환으로 인한 30포인트 하락은 실제 사용자 세션을 처리하는 원장 관리 에이전트에서 그대로 나타날 실패 유형들입니다.</p>
<p>특화된 도구 사용 모델이 범용 프론티어 모델보다 성능이 떨어진다는 발견은 특히 시사하는 바가 큽니다. 비용 절감을 위해 Beancount 전용 도구 호출 예제로 더 작은 오픈 소스 모델을 파인튜닝하려 한다면, WildToolBench는 이러한 특화가 실제 사용자 행동 분포에 대한 견고함을 희생시킬 수 있다는 직접적인 경고를 보냅니다. 최적 경로 비율 결과도 중요합니다. 작업을 완료하기 위해 두 배의 API 호출을 사용하는 에이전트는 비효율적일 뿐만 아니라, 쓰기 작업의 경우 불필요한 중간 호출이 원장을 일관성 없는 중간 상태로 남길 위험이 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음-읽을거리">다음 읽을거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/10/wildtoolbench-benchmarking-llm-tool-use-in-the-wild#%EB%8B%A4%EC%9D%8C-%EC%9D%BD%EC%9D%84%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="다음 읽을거리에 대한 직접 링크" title="다음 읽을거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs</strong> (arXiv:2307.16789, ICLR 2024) — WildToolBench가 명시적으로 대조군으로 삼는 기초 학습 프레임워크입니다. 이 모델의 합성 평가 설계를 이해하면 실제 실행 환경이 무엇을 더해주는지 명확해집니다.</li>
<li class=""><strong>τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains</strong> (arXiv:2406.12045) — 현실적인 멀티턴 도구 사용에 관한 가장 유사한 선행 연구입니다. τ-bench의 소매/항공 도메인과 WildToolBench의 공용 API 범위를 비교해 보면 과제가 얼마나 일반화되는지 알 수 있습니다.</li>
<li class=""><strong>AFlow: Automating Agentic Workflow Generation</strong> (arXiv:2410.10762, ICLR 2025 oral) — 지시어 전환 문제가 학습 데이터 확장보다는 더 나은 에이전트 워크플로우를 자동 발견함으로써 해결될 수 있다면, AFlow는 이를 수행하는 가장 신뢰할 만한 메커니즘입니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Automation" term="Automation"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Technology" term="Technology"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[LLM의 신뢰도와 캘리브레이션: 연구 결과가 실제로 보여주는 것에 대한 서베이]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/09/confidence-estimation-calibration-llms-survey</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/09/confidence-estimation-calibration-llms-survey"/>
        <updated>2026-07-09T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[화이트박스 로짓 접근법, 일관성 기반 SelfCheckGPT, 의미론적 엔트로피 등 LLM 신뢰도 추정 및 캘리브레이션 방법에 대한 체계적인 서베이에 따르면, GPT-4의 언어화된 신뢰도 점수는 AUROC 약 62.7%에 불과하여 우연보다 약간 높은 수준인 것으로 나타났습니다. 이는 금융 및 회계 분야에서 불확실성을 인지하는 에이전트를 배포할 때 직접적인 시사점을 제공합니다.]]></summary>
        <content type="html"><![CDATA[<p>지난주에 저는 저렴한 모델의 불확실성이 캘리브레이션된 임계값을 초과할 때 에이전트의 결정을 고가의 폴백 모델로 라우팅하는 ReDAct에 대해 다뤘습니다. 해당 논문은 "불확실성"에 대해 많은 부분을 모호하게 넘어가는데, 이 분야에서 불확실성을 측정하고 캘리브레이션하는 것에 대해 실제로 무엇이 알려져 있는지 잠시 멈추어 이해해 볼 가치가 있습니다. Geng 등의 "대규모 언어 모델의 신뢰도 추정 및 캘리브레이션에 관한 서베이"(NAACL 2024)는 무엇이 효과가 있고 무엇이 그렇지 않은지, 그리고 아직 아무도 측정하지 않은 것이 무엇인지에 대한 체계적인 분류를 제공하는 좋은 시작점입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문">논문<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/09/confidence-estimation-calibration-llms-survey#%EB%85%BC%EB%AC%B8" class="hash-link" aria-label="논문에 대한 직접 링크" title="논문에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=LLM%20%EC%8B%A0%EB%A2%B0%EB%8F%84%EC%99%80%20%EC%BA%99%EB%A6%AC%EB%B8%8C%EB%A0%88%EC%9D%B4%EC%85%98%3A%20%EC%97%B0%EA%B5%AC%20%EA%B2%B0%EA%B3%BC%EA%B0%80%20%EC%8B%A4%EC%A0%9C%EB%A1%9C%20%EB%B3%B4%EC%97%AC%EC%A3%BC%EB%8A%94%20%EA%B2%83%EC%97%90%20%EB%8C%80%ED%95%9C%20%EC%84%9C%EB%B2%A0%EC%9D%B4" alt="2026-07-09-confidence-estimation-calibration-llms-survey" class="img_ev3q"></p>
<p>Geng, Cai, Wang, Koeppl, Nakov, Gurevych는 객관식 QA부터 개방형 생성 및 기계 번역에 이르기까지 다양한 작업에서 LLM 신뢰도 추정 및 캘리브레이션에 관한 최신 문헌들을 조사했습니다. 핵심 문제: LLM은 매우 정확하면서도 외부에서는 구별하기 어려운 방식으로 완전히 신뢰할 수 없을 수도 있다는 점입니다. 이 서베이는 해결 공간을 모델 내부 상태에 대한 접근 권한을 활용하는 화이트박스(white-box) 방식과 모델을 불투명하게 취급하는 블랙박스(black-box) 방식이라는 두 가지 주요 분기로 정리하며, 각 분기 내에서 신뢰도를 추정하는 것과 사후적으로 캘리브레이션하는 것을 더 세분화하여 구분합니다.</p>
<p>이 논문은 NAACL 2024(6577~6595페이지)에서 발표되었으며, TU Darmstadt, MBZUAI, Mohamed bin Zayed University of AI의 팀이 2023년 11월 제출본을 2024년 3월에 개정한 것입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-개념">주요 개념<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/09/confidence-estimation-calibration-llms-survey#%EC%A3%BC%EC%9A%94-%EA%B0%9C%EB%85%90" class="hash-link" aria-label="주요 개념에 대한 직접 링크" title="주요 개념에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">
<p><strong>로짓을 통한 화이트박스 신뢰도</strong>: 가장 간단한 접근 방식은 토큰 수준의 확률이나 길이에 따라 정규화된 로그 가능도를 신뢰도 신호로 사용하는 것입니다. 이러한 방법은 효과가 있지만 근본적인 모호함에 직면합니다. 낮은 토큰 확률은 사실 관계에 대한 낮은 신뢰도를 반영할 수도 있지만, 단순히 특이한 표현 방식일 수도 있습니다. 즉, 모델이 근본적인 사실에 대해서는 확신하면서도 단어 선택에 대해서는 확신하지 못할 수 있습니다.</p>
</li>
<li class="">
<p><strong>일관성 기반 블랙박스 신뢰도(SelfCheckGPT)</strong>: Manakul 등(EMNLP 2023)은 여러 개의 완결된 문장을 샘플링하고 BERTScore, NLI 또는 n-gram 중첩을 사용하여 상호 일관성을 점수로 매깁니다. 로짓 접근 권한이 필요하지 않습니다. 핵심 통찰: LLM이 잘 아는 사실의 경우 반복된 샘플이 수렴하지만, 환각된 사실의 경우 발산합니다.</p>
</li>
<li class="">
<p><strong>의미론적 엔트로피</strong>: Farquhar 등(<em>Nature</em>, 2024)은 엔트로피를 계산하기 전에 의미적으로 동등한 답변들을 클러스터링합니다. LLM은 "파리(Paris)"와 "프랑스의 수도"를 다르게 표현할 수 있습니다. 단순 토큰 엔트로피는 이를 발산하는 것으로 취급하지만, 의미론적 엔트로피는 그렇지 않습니다. 이는 이 서베이가 맥락화한 토큰 수준 일관성보다 한 단계 더 나아간 정성적 진보입니다.</p>
</li>
<li class="">
<p><strong>언어화된 신뢰도의 한계</strong>: 신뢰도 백분율을 출력하도록 요청받았을 때, 모델은 과잉 신뢰(overconfidence) 상태로 무너집니다. 실증 연구(Groot 등, ACL 2024의 TrustNLP)에 따르면 GPT-3, GPT-3.5, Vicuna 모두 언어화된 신뢰도에 대해 평균 기대 캘리브레이션 오차(ECE)가 0.377을 초과하며, 실제 정확도와 상관없이 예측값이 90–100% 범위에 집중되는 것으로 나타났습니다. 평가된 모델 중 캘리브레이션이 가장 잘 된 GPT-4조차도 언어화된 신뢰도를 사용하여 정답과 오답을 구별할 때 AUROC가 약 62.7%에 불과해 우연보다 조금 나은 수준입니다.</p>
</li>
<li class="">
<p><strong>작업에 따라 다른 캘리브레이션 기법</strong>: 분류 작업의 경우, 빈 "[N/A]" 프롬프트로 추정된 클래스 사전 편향을 빼는 맥락적 캘리브레이션과 위치 편향 제거(PriDE)가 알려진 체계적 편향을 해결합니다. 생성 작업의 경우, 시퀀스 가능도 캘리브레이션(SLiC)은 순위가 매겨진 완결문들에 대해 모델을 미세 조정합니다. 가장 간단한 사후 수정법인 온도 스케일링(Temperature scaling)은 여전히 많은 환경에서 경쟁력이 있습니다.</p>
</li>
<li class="">
<p><strong>통합 벤치마크의 부재</strong>: 이 서베이의 가장 뼈아픈 구조적 관찰은 작업과 도메인 전반에 걸쳐 신뢰도 추정 방법을 아우르는 단일 벤치마크가 없다는 점입니다. 이로 인해 방법들을 엄격하게 비교하는 것이 거의 불가능합니다. 이 분야는 사과와 오렌지를 비교하고 있는 격입니다.</p>
</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="무엇이-유효하고-무엇이-그렇지-않은가">무엇이 유효하고 무엇이 그렇지 않은가<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/09/confidence-estimation-calibration-llms-survey#%EB%AC%B4%EC%97%87%EC%9D%B4-%EC%9C%A0%ED%9A%A8%ED%95%98%EA%B3%A0-%EB%AC%B4%EC%97%87%EC%9D%B4-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80%EA%B0%80" class="hash-link" aria-label="무엇이 유효하고 무엇이 그렇지 않은가에 대한 직접 링크" title="무엇이 유효하고 무엇이 그렇지 않은가에 대한 직접 링크" translate="no">​</a></h2>
<p>분류 체계는 견고합니다. 화이트박스 대 블랙박스 구분은 시스템 설계에 진정으로 유용하며, 로짓 기반 방법에 대한 처리는 그 한계에 대해 솔직합니다. 저자들은 토큰 확률이 사실적 신뢰도와 어휘적 불확실성을 혼동한다는 점을 직접 지적합니다. 실무자들은 이러한 혼동을 과소평가하곤 합니다.</p>
<p>이 서베이에서 아쉬운 점은 주로 설명 위주라는 것입니다. 방법들을 직접 비교하는 실험적 벤치마크가 거의 없으며, 저자들도 이를 명백한 한계로 인정합니다. 설계 공간 지도는 명확히 얻을 수 있지만, 새로운 작업에 어떤 방법을 사용해야 할지에 대한 지침은 얻기 어렵습니다.</p>
<p>언어화된 신뢰도 결과(GPT-4의 AUROC <del>62.7%)는 LLM을 프로덕션에 배포하는 사람이라면 누구나 알고 있어야 할 정석적인 지식이 되어야 합니다. 하지만 현실은 그렇지 않습니다. 사람들은 여전히 "1</del>10점 척도에서 얼마나 확신합니까?"라고 묻는 프롬프트를 배포하고 그 답변을 의미 있는 것으로 취급합니다. 하지만 그것은 의미가 없습니다.</p>
<p>이 서베이는 RLHF 캘리브레이션 문제에 대해서도 미흡합니다. 인간 피드백을 통한 사후 학습이 모델의 캘리브레이션을 개선하는지 아니면 악화시키는지에 대해서는 양쪽 모두의 증거가 있으며, 서베이는 이를 대부분 회피합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="이것이-금융-ai에-중요한-이유">이것이 금융 AI에 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/09/confidence-estimation-calibration-llms-survey#%EC%9D%B4%EA%B2%83%EC%9D%B4-%EA%B8%88%EC%9C%B5-ai%EC%97%90-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="이것이 금융 AI에 중요한 이유에 대한 직접 링크" title="이것이 금융 AI에 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>ReDAct는 저렴한 모델로부터 캘리브레이션된 불확실성 신호를 얻는 것에 안전성을 걸고 있습니다. 이 서베이는 그것이 실제로 얼마나 어려운지를 명확히 보여줍니다. 로짓 기반 신호는 화이트박스 환경에서 사용할 수 있지만 어휘적 불확실성과 사실적 불확실성을 혼동합니다. 일관성 기반 방법은 블랙박스 환경에서 작동하지만 결정당 여러 개의 샘플이 필요하므로, 대량의 트랜잭션 항목을 처리하는 고처리량 Beancount 기록 에이전트에게는 비용이 많이 듭니다.</p>
<p>Bean Labs에 가장 유용한 발견은 의미론적 엔트로피가 일관성을 측정하기 전에 의미적으로 동등한 답변들을 클러스터링한다는 점입니다. 이는 모델이 동일한 차변/대변 관계를 여러 통사적으로 뚜렷한 형태로 표현할 수 있는 원장 항목(ledger entries)에서 정확히 중요한 부분입니다. Beancount 에이전트는 계정 이름이나 금액을 환각하고 있는지 감지하기 위해 원시 토큰 수준의 분산이 아닌, 샘플링된 원장 항목 완결문들에 대해 의미론적 클러스터링을 사용해야 합니다.</p>
<p>언어화된 신뢰도의 캘리브레이션 실패는 사용자에게 "AI가 얼마나 확신하나요?"라고 표시하는 모든 UI에 대한 직접적인 경고입니다. 모델이 생성하는 숫자를 믿지 마십시오. 대신 외부 캘리브레이터나 일관성 기반 방법을 사용하거나, 아예 표시하지 마십시오.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음에-읽을거리">다음에 읽을거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/09/confidence-estimation-calibration-llms-survey#%EB%8B%A4%EC%9D%8C%EC%97%90-%EC%9D%BD%EC%9D%84%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="다음에 읽을거리에 대한 직접 링크" title="다음에 읽을거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">Farquhar 등, "의미론적 엔트로피를 이용한 대규모 언어 모델의 환각 탐지", <em>Nature</em>, 2024 — 이 서베이 프레임워크에서 나온 가장 엄격한 방법으로, 서베이의 요약보다는 전문을 읽어볼 가치가 있습니다.</li>
<li class="">Manakul 등, "SelfCheckGPT: 생성형 대규모 언어 모델을 위한 제로 리소스 블랙박스 환각 탐지", EMNLP 2023 (arXiv:2303.08896) — 정석적인 일관성 기반 방법으로, 블랙박스 신뢰도 신호를 배포하기 전에 반드시 이해해야 합니다.</li>
<li class="">Groot 등, "과잉 신뢰가 핵심: 대규모 언어 및 시각-언어 모델에서의 언어화된 불확실성 평가", TrustNLP at ACL 2024 (arXiv:2405.02917) — 모델과 작업 전반에 걸쳐 언어화된 신뢰도가 어떻게 무너지는지에 대한 가장 철저한 실증적 감사입니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="LLM" term="LLM"/>
        <category label="AI" term="AI"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Trust" term="Trust"/>
        <category label="Finance" term="Finance"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Hallucination Detection" term="Hallucination Detection"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[JSONSchemaBench: 실제 스키마 복잡성으로 인한 LLM 구조적 출력 보장 실패]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/08/jsonschemabench-structured-outputs-language-models</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/08/jsonschemabench-structured-outputs-language-models"/>
        <updated>2026-07-08T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[JSONSchemaBench는 9,558개의 실제 JSON 스키마를 6개의 제약 조건 기반 디코딩 프레임워크에서 테스트했습니다. 그 결과, 스키마 복잡성으로 인해 단순 스키마에서의 86% 커버리지가 복잡한 스키마에서는 3%로 급감했으며, XGrammar는 38개의 비준수 출력을 조용히 내보냈고, 어떤 프레임워크도 45개의 JSON 스키마 기능 카테고리를 모두 지원하지 못했습니다.]]></summary>
        <content type="html"><![CDATA[<p>대부분의 팀은 제약 조건 기반 디코딩(constrained decoding)을 해결된 문제로 여깁니다. JSON 스키마를 추가하면 유효한 JSON을 얻을 수 있다고 믿기 때문입니다. JSONSchemaBench (arXiv:2501.10868)는 9,558개의 실제 스키마를 대상으로 이러한 가정을 테스트한 최초의 체계적인 시도이며, 그 결과는 마케팅 문구만큼 안심할 수준이 아닙니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-소개">논문 소개<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/08/jsonschemabench-structured-outputs-language-models#%EB%85%BC%EB%AC%B8-%EC%86%8C%EA%B0%9C" class="hash-link" aria-label="논문 소개에 대한 직접 링크" title="논문 소개에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=JSONSchemaBench%3A%20%EC%8B%A4%EC%A0%9C%20%EC%8A%A4%ED%82%A4%EB%A7%88%20%EB%B3%B5%EC%9E%A1%EC%84%B1%EC%9C%BC%EB%A1%9C%20%EC%9D%B8%ED%95%9C%20LLM%20%EA%B5%AC%EC%A1%B0%EC%A0%81%20%EC%B6%9C%EB%A0%A5%20%EB%B3%B4%EC%9E%A5%20%EC%8B%A4%ED%83%9C" alt="2026-07-08-jsonschemabench-structured-outputs-language-models" class="img_ev3q"></p>
<p>Microsoft Research의 Saibo Geng, Hudson Cooper, Michał Moskal 및 동료들은 실제 운영 환경의 소스에서 추출한 9,558개의 스키마 벤치마크인 JSONSchemaBench를 소개합니다. 여기에는 GlaiveAI 함수 호출 시그니처, 사소한 수준부터 극도로 복잡한 수준까지 계층화된 GitHub 리포지토리, Kubernetes API 설정, Snowplow 이벤트 분석 스키마, JSONSchemaStore 컬렉션 등이 포함됩니다. 연구진은 세 가지 축인 커버리지(프레임워크가 처리할 수 있는 스키마의 비율), 효율성(제약 없는 생성 대비 초당 토큰 오버헤드), 품질(다운스트림 작업 정확도)을 기준으로 Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs, Gemini 등 6개의 제약 조건 기반 디코딩 프레임워크를 평가합니다. 평가 기준에는 준수하는 엔진이 지원해야 할 45개 기능 카테고리를 문서화한 공식 JSON 스키마 테스트 스위트도 포함되었습니다.</p>
<p>이 논문의 핵심 주장은 스키마 복잡성이 유능한 프레임워크와 취약한 프레임워크를 가르는 결정적인 변수이며, 세 가지 축 모두에서 압도적인 우위를 점하는 단일 프레임워크는 없다는 것입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-개념">주요 개념<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/08/jsonschemabench-structured-outputs-language-models#%EC%A3%BC%EC%9A%94-%EA%B0%9C%EB%85%90" class="hash-link" aria-label="주요 개념에 대한 직접 링크" title="주요 개념에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>스키마 복잡성에 따른 커버리지 급감.</strong> 단순한 GlaiveAI 스키마에서는 모든 프레임워크가 86% 이상의 점수를 기록했습니다. 그러나 다단계 중첩, 재귀적 정의, 복잡한 패턴 제약이 포함된 GitHub-Hard 스키마에서는 Guidance가 41%, Llamacpp이 39%, XGrammar가 28%로 떨어졌으며, Outlines는 3%라는 처참한 수치를 기록했습니다. OpenAI는 GitHub-Hard에서 9%에 그쳤고, Gemini는 중간 난이도 이상의 스키마에서 유효한 출력을 전혀 생성하지 못했습니다.</li>
<li class=""><strong>Kubernetes에서 드러난 XGrammar의 특정 약점.</strong> XGrammar는 속도에 대한 강점에도 불구하고 Kubernetes 스키마에서 단 7%의 커버리지만 달성했습니다. 이는 해당 스키마들이 문맥 의존적(context-dependent) 패턴에 의존하는 반면, XGrammar의 문맥 독립적(context-independent) 사전 계산 방식으로는 이를 처리할 수 없기 때문으로 보입니다. 프로덕션 에이전트에게 Kubernetes 설정을 포함한 벤치마크 커버리지는 선택이 아닌 필수입니다.</li>
<li class=""><strong>컴파일 실패보다 위험한 과소 제약(Under-constrained).</strong> XGrammar는 JSON 스키마 테스트 스위트에서 38개의 과소 제약 오류를 보였습니다. 즉, 선언된 스키마를 위반하는 JSON을 생성하면서도 성공했다고 보고하는 것입니다. Guidance는 이러한 오류가 단 1건뿐이었습니다. 쓰기 작업(write-back) 에이전트의 경우, 컴파일 오류는 설계 시점에 발견되지만, 과소 제약 오류는 아무런 신호 없이 런타임에 데이터를 오염시킵니다.</li>
<li class=""><strong>Guidance의 패스트 포워딩(fast-forwarding)을 통한 실질적인 50% 속도 향상.</strong> 고정된 객체 구조의 필드 이름과 같이 긴 결정론적 시퀀스가 존재할 때, Guidance는 한 번의 디코딩 단계에서 여러 토큰을 전진시킬 수 있습니다. A100의 Llama-3.1-8B에서 Guidance는 출력 토큰당 6<del>9ms로 실행되는 반면, 제약 없는 생성은 15</del>16ms가 소요됩니다. Outlines는 토큰당 30<del>46ms로 제약 없는 생성보다 느린데, 이는 주로 스키마당 3</del>8초가 걸리는 사전 오토마톤 컴파일 때문입니다.</li>
<li class=""><strong>제약 조건 기반 디코딩의 추론 정확도 소폭 향상.</strong> GSM8K(수학)에서 Guidance는 정확도를 80.1%(제약 없음)에서 83.8%로 끌어올렸습니다. Last Letter 및 Shuffle Objects에서도 1~3포인트의 향상이 있었습니다. 이는 JSON 형식을 강제하면 답변 품질이 떨어진다는 널리 알려진 우려를 반박하는 결과입니다. 하지만 효과 크기가 작기 때문에 형식 선택이 프레임워크 선정의 주된 이유가 되어서는 안 됩니다.</li>
<li class=""><strong>45개 JSON 스키마 기능 카테고리를 모두 지원하는 프레임워크는 없음.</strong> Guidance는 13개, Llamacpp와 XGrammar는 각각 1개, Outlines는 0개를 지원합니다. 실질적인 의미는 <code>if/then/else</code>, <code>unevaluatedProperties</code>, 또는 재귀적 <code>$ref</code> 정의를 사용하는 모든 스키마가 어떤 엔진을 사용하느냐에 따라 예측 불가능하게 작동할 수 있다는 것입니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/08/jsonschemabench-structured-outputs-language-models#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>이 벤치마크의 가장 큰 공헌은 스키마 소싱에 있습니다. 이전의 평가는 조잡한 스키마나 단일 소스 컬렉션을 사용했습니다. 함수 호출 시그니처와 함께 Kubernetes 설정을 포함한 것은 적절한 수준의 적대적 다양성을 제공합니다. 또한 복잡성 계층화(trivial부터 ultra까지)는 실무자들에게 보정 곡선을 제공합니다. 여러분의 스키마가 GlaiveAI 함수 호출과 비슷하다면 XGrammar나 Guidance 모두 괜찮지만, Kubernetes 매니페스트와 비슷하다면 선택지는 급격히 좁아집니다.</p>
<p>주요 약점은 단일 샘플 그리디(greedy) 평가 방식입니다. 스키마당 한 번의 생성으로 커버리지를 측정하는 것은 실제 성능을 과소평가할 수 있습니다. 프레임워크가 20%의 확률로 실패하더라도 재시도 시 성공할 수 있기 때문입니다. 논문에서도 이를 인정하지만, 실패 시 재시도하는 프로덕션 시스템에서 중요한 온도 샘플링 기반의 pass@k 수치는 보고하지 않았습니다.</p>
<p>또한 비교 대상에 서로 다른 모델이 섞여 있습니다. 오픈 소스 프레임워크(Guidance, Outlines, Llamacpp, XGrammar)는 Llama-3.2-1B에서 테스트된 반면, OpenAI와 Gemini는 자체 비공개 모델을 사용했습니다. OpenAI의 GitHub-Hard 커버리지 9%는 제약 조건 기반 디코딩 아키텍처만큼이나 모델 자체의 성능을 반영할 가능성이 큽니다. 공정한 비교를 위해서는 통제된 모델 접근이 필요하지만, 저자들이 상용 제공업체에 이를 강제할 수는 없었을 것입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-aifinance-ai에-중요한-이유">금융 AI(Finance AI)에 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/08/jsonschemabench-structured-outputs-language-models#%EA%B8%88%EC%9C%B5-aifinance-ai%EC%97%90-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI(Finance AI)에 중요한 이유에 대한 직접 링크" title="금융 AI(Finance AI)에 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>모든 Beancount 라이트백(write-back) 에이전트는 구조적 출력을 생성합니다. 에이전트가 Beancount 지시어를 <code>.beancount</code> 구문으로 변환하기 전에 JSON으로 생성하거나, JSON 스키마를 통해 도구를 호출한다면, JSON 생성의 신뢰성은 단순한 세부 사항이 아니라 시스템의 핵심입니다. FinTrace 논문은 프론티어 모델들이 도구 출력에 대한 추론에 실패한다는 것을 보여주었습니다. JSONSchemaBench는 또 다른 문제를 드러냅니다. 추론 이전 단계인 포매팅 레이어에서조차 규격을 준수하지 않는 출력을 조용히 내보낼 수 있다는 점입니다.</p>
<p>특히 Kubernetes 결과는 Beancount에 시사하는 바가 큽니다. 장부(Ledger) 스키마는 단순한 키-값 쌍의 나열이 아닙니다. 계정 계층 구조, 트랜잭션 메타데이터, 태그 구조는 Kubernetes API 객체와 유사하게 중첩된 재귀 패턴을 생성합니다. Kubernetes에서 7%의 점수를 받은 프레임워크는 토큰당 오버헤드가 아무리 빠르더라도 복잡한 장부 스키마를 처리할 준비가 되지 않은 것입니다.</p>
<p>가장 우려되는 부분은 과소 제약(under-constrained) 실패 모드입니다. XGrammar를 사용하는 Beancount 에이전트는 프레임워크의 내부 유효성 검사는 통과하지만 실제 스키마는 위반하는 트랜잭션을 생성할 수 있으며, 이 경우 에이전트는 재시도할 이유를 찾지 못합니다. 소리 없는 데이터 오염은 눈에 보이는 실패보다 훨씬 위험합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어보기">더 읽어보기<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/08/jsonschemabench-structured-outputs-language-models#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%B4%EA%B8%B0" class="hash-link" aria-label="더 읽어보기에 대한 직접 링크" title="더 읽어보기에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>XGrammar</strong> (arXiv:2411.15100, Dong et al.) — 테스트된 가장 빠른 프레임워크 중 하나의 기술 논문으로, 문맥 독립/의존 토큰 분할과 Kubernetes 스키마가 왜 이를 압박하는지 설명합니다.</li>
<li class=""><strong>Grammar-Aligned Decoding / ASAp</strong> (NeurIPS 2024) — 제약 조건 기반 디코딩의 토큰 마스킹이 모델의 확률 분포를 왜곡할 수 있음을 보여주고 수정된 샘플링 알고리즘을 제안합니다. 이 벤치마크가 간접적으로만 측정한 품질 문제에 대한 이론적 근거를 제공합니다.</li>
<li class=""><strong>XGrammar-2</strong> (arXiv:2601.04426) — 멀티턴 세션 중에 스키마 자체가 변하는 에이전트 환경의 동적 스키마로 XGrammar를 확장한 후속 연구로, 활성화된 계정 유형에 따라 출력 형식을 조정하는 Beancount 에이전트와 직접적인 관련이 있습니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="LLM" term="LLM"/>
        <category label="AI" term="AI"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Automation" term="Automation"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Performance" term="Performance"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[FinMCP-Bench: MCP 기반 실제 금융 도구 사용을 위한 LLM 에이전트 벤치마킹]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/07/finmcp-bench-llm-agents-financial-tool-use-model-context-protocol</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/07/finmcp-bench-llm-agents-financial-tool-use-model-context-protocol"/>
        <updated>2026-07-07T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[FinMCP-Bench는 65개의 MCP 서버를 기반으로 하는 613개의 실제 금융 도구 사용 작업에서 6개의 LLM 모델을 평가합니다. 가장 우수한 모델도 멀티턴 작업에서 3.08%의 완전 일치(exact match) 점수를 기록하여, 단일 도구 사용 대비 멀티턴 시나리오에서 성능이 20배 하락함을 보여줍니다.]]></summary>
        <content type="html"><![CDATA[<p>MCP는 LLM 도구 사용을 위한 사실상의 연결 표준이 되었습니다. Anthropic이 2024년 말에 이를 도입했으며, 2026년 초까지 모든 주요 모델 제공업체가 이를 채택했습니다. FinMCP-Bench(arXiv:2603.24943, ICASSP 2026)는 금융 에이전트를 위해 특별히 구축된 실제 MCP 도구 서버 기반의 첫 번째 벤치마크이며, 표준화된 배관(plumbing)이 에이전트가 유용한 금융 작업을 수행하는 데 실제로 도움이 되는지 확인할 수 있는 적절한 시점에 등장했습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-소개">논문 소개<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/07/finmcp-bench-llm-agents-financial-tool-use-model-context-protocol#%EB%85%BC%EB%AC%B8-%EC%86%8C%EA%B0%9C" class="hash-link" aria-label="논문 소개에 대한 직접 링크" title="논문 소개에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=FinMCP-Bench%3A%20MCP%20%EA%B8%B0%EB%B0%98%20%EC%8B%A4%EC%A0%9C%20%EA%B8%88%EC%9C%B5%20%EB%8F%84%EA%B5%AC%20%EC%82%AC%EC%9A%A9%EC%9D%84%20%EC%9C%84%ED%95%9C%20LLM%20%EC%9D%B4%EC%A0%84%ED%8A%B8%20%EB%B2%A4%EC%B9%98%EB%A7%88%ED%82%B9" alt="2026-07-07-finmcp-bench-llm-agents-financial-tool-use-model-context-protocol" class="img_ev3q"></p>
<p>Alibaba Cloud Qwen DianJin 팀, YINGMI Wealth Management, 소주 대학교(Soochow University)의 Jie Zhu, Yimin Tian 및 동료들은 10개의 금융 시나리오 카테고리와 33개의 하위 시나리오를 아우르는 613개의 샘플 평가 모음인 FinMCP-Bench를 발표했습니다. 도구들은 가짜(mocked)가 아닙니다. Qieman 앱 금융 비서의 실제 프로덕션 로그에서 추출한 65개의 실제 MCP 준수 금융 도구 서버가 이 벤치마크를 뒷받침합니다. 저자들은 샘플을 세 가지 유형으로 분류했습니다: 145개의 단일 도구, 249개의 다중 도구, 219개의 멀티턴 샘플입니다. 이들은 Qwen3 제품군(4B, 30B, 235B 파라미터, 모두 확장 추론 기능 포함), DeepSeek-R1, GPT-OSS-20B, Seed-OSS-36B 등 6개 모델을 테스트했습니다. 핵심 평가 지표는 도구 정밀도(Tool Precision), 도구 재현율(Tool Recall), 도구 F1 점수, 그리고 시퀀스의 모든 도구 호출이 정확해야 하는 완전 일치율(Exact Match Rate, EMR)입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/07/finmcp-bench-llm-agents-financial-tool-use-model-context-protocol#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>평가 기반으로서의 MCP</strong>: 합성 API 스키마 대신 실제 MCP 서버 정의를 사용함으로써, 벤치마크 평가와 실제 배포된 금융 시스템에서 에이전트가 직면하는 상황 사이의 큰 격차를 해소합니다.</li>
<li class=""><strong>세 가지 난이도 분할</strong>: 단일 도구, 다중 도구, 멀티턴 샘플은 단순한 수량 차이가 아니라 질적으로 다른 실패 모드를 드러냅니다.</li>
<li class=""><strong>멀티턴 성능 붕괴</strong>: 가장 우수한 모델(Qwen3-235B)은 단일 도구에서 60% EMR, 다중 도구에서 10.62% EMR, 멀티턴에서 3.08% EMR을 기록했습니다. 단일 도구에서 멀티턴으로 갈 때 성능이 20배 하락합니다.</li>
<li class=""><strong>도구 F1은 더 관대함</strong>: 동일한 모델이 세 가지 설정에서 각각 66.85%, 69.42%, 41.56%의 TF1(Tool F1)을 기록했습니다. 이는 모델이 종종 올바른 도구를 선택하지만 순서, 파라미터화 또는 대화 추적에서 실수를 한다는 것을 보여줍니다.</li>
<li class=""><strong>단일 도구에서 재현율이 정밀도를 압도함</strong>: 모델은 불확실할 때 도구를 덜 호출하기보다는 더 많이 호출하는 경향이 있습니다. 이는 금융 작업에서 더 안전한 실패 모드이긴 하지만, 여전히 불필요한 API 호출과 추론 추적의 노이즈를 의미합니다.</li>
<li class=""><strong>비단조적 크기 확장성</strong>: Qwen3-30B가 모든 하위 시나리오에서 Qwen3-4B를 일관되게 능가하지는 않았으며, 이는 다단계 도구 사용에서 항상 더 큰 모델이 유리하다는 가정을 깨뜨립니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-한계점">유효한 점과 한계점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/07/finmcp-bench-llm-agents-financial-tool-use-model-context-protocol#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%ED%95%9C%EA%B3%84%EC%A0%90" class="hash-link" aria-label="유효한 점과 한계점에 대한 직접 링크" title="유효한 점과 한계점에 대한 직접 링크" translate="no">​</a></h2>
<p>단일 도구 예시의 소스로 실제 프로덕션 로그를 사용한 것은 이 연구에서 가장 강력한 방법론적 선택입니다. 이는 연구자가 만든 시나리오가 아니라 실제 사용자 행동에 벤치마크의 근거를 두는 것으로, 금융 AI 문헌에서는 드문 일입니다. 다중 도구 및 멀티턴 샘플은 종속성 그래프와 역할극 프롬프트를 사용하여 인위적으로 확장되었습니다. 이는 라벨링 비용을 고려할 때 합리적이지만, 합성 프로세스가 실제 사용자가 작성하는 것보다 더 명확하고 정제된 쿼리를 생성하는 경향이 있다는 위험이 있습니다. 멀티턴에서의 3.08% EMR은 놀라운 수치이지만 신중하게 해석해야 합니다. EMR은 전체 시퀀스가 정확해야 하므로 중간에 도구 호출 하나만 틀려도 전체 작업이 실패로 처리됩니다. 이는 엄격하고 다소 비현실적인 프로덕션 기준일 수 있으며, TF1과 같은 부분 점수 지표가 더 미묘한 상황을 보여줍니다.</p>
<p>논문에서 다루지 않은 점: 성능 격차가 주로 입력 이해 문제(사용자가 원하는 것을 오해함), 출력 형식 문제(의도는 맞지만 도구 호출 형식이 잘못됨), 또는 추론 문제(중간 결론이 틀림) 중 무엇 때문인지에 대한 분석이 없습니다. 이러한 분해 없이는 엔지니어링 노력을 어디에 집중해야 할지 알기 어렵습니다. 또한 논문은 모델을 개별적으로 평가하며, 검증이나 성찰(reflection) 단계를 추가하는 것이 멀티턴 성능에 변화를 주는지 테스트하지 않았습니다.</p>
<p>또한 벤치마크가 Qieman의 특정 65개 도구와 깊게 연관되어 있어, 도구 목록이 다른 다른 금융 플랫폼으로 결과를 일반화하는 데 한계가 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에서-이것이-중요한-이유">금융 AI에서 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/07/finmcp-bench-llm-agents-financial-tool-use-model-context-protocol#%EA%B8%88%EC%9C%B5-ai%EC%97%90%EC%84%9C-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>FinMCP-Bench는 Beancount 쓰기(write-back) 에이전트가 실제로 수행하게 될 작업과 가장 유사한 평가입니다. 즉, 사용자 요청을 수신하고, 어떤 도구(또는 도구 체인)가 적용되는지 식별하고, 순서대로 호출하고, 후속 턴을 처리하는 과정입니다. 멀티턴 EMR 3.08%는 냉혹한 현실을 보여줍니다. 특정 날짜 범위의 계정 간 거래 세트를 재분류하고, 조정(reconciling)한 다음 보고서를 생성하는 것과 같은 다단계 장부 수정 작업을 수행하는 Beancount 에이전트는 현재 모델들이 완전 일치 기준으로 거의 예외 없이 실패하는 종류의 멀티턴, 다중 도구 작업입니다.</p>
<p>MCP 프레임워크는 직접적인 관련이 있습니다. Beancount의 Python API, beanquery 인터페이스, fava의 REST 레이어는 모두 MCP 서버로 래핑될 수 있습니다. FinMCP-Bench는 병목 현상이 프로토콜 자체가 아니라 도구 호출 시퀀스에 대한 추론에 있음을 시사합니다.</p>
<p>도구 재현율이 정밀도보다 높다(모델이 과도하게 호출함)는 발견은 쓰기 안전성에도 중요합니다. 읽기만 필요한 상황에서 장부 수정 도구를 호출하는 에이전트는 장부를 소리 없이 오염시킬 수 있습니다. 따라서 쓰기 에이전트의 주요 안전 신호로는 재현율 위주가 아닌 정밀도 위주의 평가 지표를 사용해야 합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어볼-거리">더 읽어볼 거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/07/finmcp-bench-llm-agents-financial-tool-use-model-context-protocol#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%BC-%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="더 읽어볼 거리에 대한 직접 링크" title="더 읽어볼 거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>JSONSchemaBench</strong> (arXiv:2501.10868) — 1만 개의 JSON 스키마에서 구조화된 출력의 신뢰성을 평가하며, FinMCP-Bench의 도구 호출 형식 오류가 제약된 디코딩(constrained decoding) 문제인지 직접적으로 다룹니다.</li>
<li class=""><strong>ToolLLM</strong> (arXiv:2307.16789, ICLR 2024) — FinMCP-Bench가 대조군으로 삼는 기초적인 도구 사용 학습 프레임워크입니다. 이 모델의 깊이 우선 탐색 트리 탐색 방식을 이해하면 FinMCP-Bench의 프로덕션 로그 방법론이 시사하는 바가 무엇인지 명확해집니다.</li>
<li class=""><strong>WildToolBench</strong> (arXiv:2604.06185) — 실제 야생(wild)의 사용자 쿼리에 대한 도구 사용을 평가합니다. 야생의 사용자 행동에 대해 어떤 모델도 15% 정확도를 넘지 못한다는 발견은 FinMCP-Bench의 프로덕션 로그 접근 방식을 보완합니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Automation" term="Automation"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Fintech" term="Fintech"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Reconciliation" term="Reconciliation"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[FinTrace: 금융 작업을 위한 LLM 도구 호출의 궤적 수준 평가]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/06/fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/06/fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks"/>
        <updated>2026-07-06T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[FinTrace는 9가지 지표를 통해 800개의 전문가 주석이 달린 금융 작업 궤적에서 13개의 LLM을 벤치마킹했습니다. 그 결과, 프런티어 모델들은 강력한 도구 선택 능력(F1 ~0.9)을 달성했지만, 에이전트가 도구의 반환 값을 추론하는 단계인 '정보 활용' 점수에서는 5점 만점에 3.23점에 그쳤습니다.]]></summary>
        <content type="html"><![CDATA[<p>FinTrace(arXiv:2604.10015)는 지난번에 기록했던 FinToolBench가 발표된 지 일주일 만에 등장했으며, 이 두 논문은 서로 직접적인 대화를 주고받고 있습니다. FinToolBench가 에이전트가 올바른 도구를 호출하는지를 측정한다면, FinTrace는 더 어려운 질문을 던집니다. 즉, 에이전트가 올바른 도구를 호출하더라도 실제로 그 결과를 바탕으로 추론을 수행하는가 하는 점입니다. 이 차이가 논문의 핵심이며, 제가 생각하기에는 Beancount 쓰기 작업(write-back) 에이전트 문제 전체의 핵심이기도 합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-요약">논문 요약<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/06/fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks#%EB%85%BC%EB%AC%B8-%EC%9A%94%EC%95%BD" class="hash-link" aria-label="논문 요약에 대한 직접 링크" title="논문 요약에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=FinTrace%3A%20%EA%B8%88%EC%9C%B5%20%EC%9E%91%EC%97%85%EC%9D%84%20%EC%9C%84%ED%95%9C%20LLM%20%EB%8F%84%EA%B5%AC%20%ED%98%B8%EC%B6%9C%EC%9D%98%20%EA%B6%A4%EC%A0%81%20%EC%88%98%EC%A4%80%20%ED%8F%89%EA%B0%80" alt="2026-07-06-fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks" class="img_ev3q"></p>
<p>Cao 등은 쉬움, 중간, 어려움의 세 가지 난이도 계층에 걸쳐 34개의 실제 금융 작업 카테고리를 아우르는 800개의 전문가 주석 궤적 벤치마크인 FinTrace를 소개합니다. 저자들은 네 가지 축을 따라 구성된 9가지 지표 루브릭을 중심으로 평가를 구축했습니다. 네 가지 축은 <strong>행동 정확도</strong>(도구 호출 F1, 작업 관련성), <strong>실행 효율성</strong>(단계 효율성, 중복성 점수), <strong>과정 품질</strong>(논리적 전개, 정보 활용, 진행 점수), 그리고 <strong>출력 품질</strong>(작업 통과율, 최종 답변 품질)입니다. 이들은 13개의 LLM을 평가하고, 미세 조정을 위해 엄선된 8,196개의 선호 궤적 데이터셋인 FinTrace-Training도 공개했습니다.</p>
<p>주요 주장은 프런티어 모델들이 도구 선택은 마스터했지만, 도구가 반환한 내용을 사용하는 더 어려운 단계에서는 체계적으로 실패한다는 것입니다. 벤치마크는 정보 활용, 논리적 전개, 진행 점수에 대해 5점 척도로 이를 조사하며, 도구 F1 및 단계 효율성에 대한 알고리즘 지표를 함께 사용합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/06/fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">최고 성능 모델인 Claude-Opus-4.6은 도구 호출 F1 0.896을 달성하여 강력한 선택 능력을 보여주었지만, 출력 관련 4가지 지표 중 가장 취약한 '정보 활용'에서는 5점 만점에 3.23점에 그쳤습니다.</li>
<li class="">Claude-Opus-4.6의 작업 통과율은 2.65/5, 최종 답변 품질은 3.34/5입니다. 최고 모델조차도 일관되게 정확하고 완전한 답변을 생성하지 못합니다.</li>
<li class="">Qwen-3.5-9B는 특이한 패턴을 보입니다. 도구를 거의 호출하지 않기 때문에 단계 효율성(1.000)과 중복성(1.000)은 완벽에 가깝지만, 이는 도구 호출 F1 0.109에 반영된 결과입니다. 효율적이지만 쓸모가 없습니다.</li>
<li class="">FinTrace-Training으로 학습하면 중간 과정 지표가 개선되지만(DPO를 통해 논리적 전개가 2.29에서 2.56으로, 진행 점수가 2.00에서 2.30으로 상승), 최종 답변 품질은 병목 현상에 갇혀 있습니다. 소형 모델의 경우 어떤 변형도 1~5점 척도에서 평균 1.21을 크게 넘지 못했습니다.</li>
<li class="">DPO는 치명적인 실패 모드를 억제하는 데 있어 SFT보다 우수한 성능을 보였습니다. 논리적 전개 점수가 1점인 비율이 11.9%(SFT)에서 9.5%(DPO)로 감소했습니다.</li>
<li class="">13개 모델 전체에서 보편적으로 가장 낮은 점수를 기록한 하위 카테고리는 '추론 QA(Reasoning QA)'였습니다. 여기서 Claude-Opus-4.6은 종합 점수 0.62만을 기록했으며, 이는 가장 강력한 프런티어 모델조차 공유하는 높은 벽입니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/06/fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>도구 선택과 도구 추론이 분리 가능하다는 핵심 발견은 충분히 근거가 있으며, 네 가지 축의 루브릭은 진정한 기여라고 볼 수 있습니다. FinToolBench와 같은 이전 벤치마크는 실행 추적에서 멈췄지만, FinTrace는 그 사이에서 벌어지는 일을 드러내는 LLM 판단 과정 품질 지표를 추가했습니다. 100개 샘플 검증에서 얻은 평가자 간 일치도(Cohen's κ) 0.89는 LLM 판단에 부분적으로 의존하는 벤치마크치고는 고무적입니다.</p>
<p>그럼에도 불구하고 몇 가지 방법론적 선택으로 인해 수치 그대로를 받아들이기 어려운 면이 있습니다. 34개의 작업 카테고리가 본문에 열거되지 않고 부록 B로 미뤄져 있어, 이것이 실제 금융 실무를 얼마나 대표하는지 알 수 없습니다. 난이도 계층은 벤치마크 자체의 쿼리 풀 내 백분위수 순위로 정의되는데, 이는 순환 논리적 측정입니다. '어렵다'는 것은 다른 800개 궤적에 비해 특이하다는 뜻일 뿐, 절대적인 의미에서 어렵다는 것이 아닐 수 있습니다.</p>
<p>미세 조정 분석도 아쉽습니다. FinTrace-Training으로 9B 모델을 학습시키면 중간 추론은 개선되지만 최종 답변 품질은 여전히 망가진 상태입니다. 논문은 이를 과정과 출력 사이의 "단절" 탓으로 돌리지만, 그 이유는 설명하지 않습니다. 9B 모델이 궤적의 품질과 관계없이 금융 작업에 필요한 사실 회상 및 산술 능력이 부족하다는 가장 그럴듯한 설명은 다뤄지지 않았습니다. 또한 DPO 결과를 Qwen-3.5-9B에 대해서만 보여주었기에 더 큰 모델이 더 많은 이득을 얻을 수 있는지는 알 수 없습니다.</p>
<p>전체 점수 집계 방식에 대해서도 회의적입니다. 알고리즘 지표(F1 ∈ [0,1])와 1~5점 리커트 척도의 LLM 판단 점수를 [0,1]로 정규화하여 평균을 내는 방식은 매우 다른 유형의 실패를 혼합합니다. 도구를 완전히 잘못 호출하는 모델과 올바른 도구를 호출한 뒤 그 출력을 무시하는 모델은 결코 같은 방식으로 고장 난 것이 아닙니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에서-이것이-중요한-이유">금융 AI에서 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/06/fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks#%EA%B8%88%EC%9C%B5-ai%EC%97%90%EC%84%9C-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>이 핵심 발견은 Beancount 쓰기 작업 문제와 직결됩니다. Beancount CLI 도구는 안정적으로 호출하지만 그 출력을 오해하는 에이전트(예: 재무상태표 응답을 파싱하여 잘못된 계정에 기입하는 경우)는 자동화가 없는 것보다 위험합니다. 일반 검토자에게는 올바른 것처럼 보이는, 확신에 찬 잘못된 장부 항목을 생성하기 때문입니다.</p>
<p>'정보 활용' 지표는 모든 Beancount 에이전트에서 가장 주의 깊게 살펴봐야 할 지표입니다. 통제된 금융 벤치마크에서 현재 사용 가능한 최고의 모델이 이 항목에서 3.23/5점을 기록했다는 사실은 실제 배포 환경에서 강력한 제약 조건이 되어야 합니다. 이는 해당 점수가 일관되게 4.0 이상으로 올라가기 전까지는 모든 쓰기 작업에 대해 반드시 인간의 검토가 필요함을 시사합니다.</p>
<p>또한 FinTrace는 지난주 ReDAct가 제안한 내용을 확인해 줍니다. 즉, 올바른 아키텍처는 엔드투엔드 LLM 추론이 아니라 검증을 외부화하는 파이프라인이라는 점입니다. 도구를 잘 선택하고(도구 F1 ~0.9), 실행하기 전에 결과를 별도의 검증 단계로 넘기는 에이전트가 단일 패스로 원시 도구 출력을 추론하려는 에이전트보다 훨씬 더 방어 가능한 구조입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음에-읽을거리">다음에 읽을거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/06/fintrace-trajectory-level-evaluation-llm-tool-calling-financial-tasks#%EB%8B%A4%EC%9D%8C%EC%97%90-%EC%9D%BD%EC%9D%84%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="다음에 읽을거리에 대한 직접 링크" title="다음에 읽을거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">FinMCP-Bench (arXiv:2603.24943): MCP를 도구 인터페이스 표준으로 사용하는 후속 논문으로, 읽기 목록의 다음 순서입니다. FinTrace와 직접 비교 가능하지만 다른 프로토콜 레이어에서 구축되었습니다.</li>
<li class="">"Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): 동시에 발표되었으며 금융 이외의 도구 호출을 평가합니다. 정보 활용의 격차가 도메인 특화적인지 아니면 일반적인 현상인지 명확히 해줄 것입니다.</li>
<li class="">"Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): 학습 데이터 관점에서 동일한 도구 호출 실패 모드를 목표로 하며, FinTrace-Training의 DPO가 놓치고 있는 부분을 설명해 줄 수 있습니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="LLM" term="LLM"/>
        <category label="AI" term="AI"/>
        <category label="Finance" term="Finance"/>
        <category label="Fintech" term="Fintech"/>
        <category label="Automation" term="Automation"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Machine Learning" term="Machine Learning"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[FinToolBench: 실제 금융 도구 사용에 대한 LLM 에이전트 평가]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/05/fintoolbench-evaluating-llm-agents-real-world-financial-tool-use</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/05/fintoolbench-evaluating-llm-agents-real-world-financial-tool-use"/>
        <updated>2026-07-05T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[FinToolBench는 760개의 실시간 금융 API 도구와 295개의 실행 가능한 쿼리를 결합하여 실제 금융 작업에 대한 LLM 에이전트를 벤치마킹합니다. GPT-4o의 보수적인 22.7% 호출률이 Qwen3-8B의 공격적인 87.1% TIR보다 높은 답변 품질(CSS 0.670)을 제공하는 반면, 의도 불일치(intent mismatch)는 모든 테스트 모델에서 50%를 초과하는 것으로 나타났습니다.]]></summary>
        <content type="html"><![CDATA[<p>대부분의 금융 AI 벤치마크는 모델이 문서를 읽을 수 있는지를 테스트합니다. FinToolBench는 모델이 무언가를 <em>수행</em>할 수 있는지, 즉 실제 API를 호출하고 현재 시장 데이터를 가져와 정확한 답변을 반환할 수 있는지를 테스트합니다. 이는 실제 금융 업무를 자동화하려는 모든 시스템에 있어 매우 중요한 격차이며, 제가 누군가 엄격하게 해결해 주기를 기다려온 부분이기도 합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-요약">논문 요약<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/05/fintoolbench-evaluating-llm-agents-real-world-financial-tool-use#%EB%85%BC%EB%AC%B8-%EC%9A%94%EC%95%BD" class="hash-link" aria-label="논문 요약에 대한 직접 링크" title="논문 요약에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=FinToolBench%3A%20%EC%8B%A4%EC%A0%9C%20%EA%B8%88%EC%9C%B5%20%EB%8F%84%EA%B5%AC%20%EC%82%AC%EC%9A%A9%EC%97%90%20%EB%8C%80%ED%95%9C%20LLM%20%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8%20%ED%8F%89%EA%B0%80" alt="2026-07-05-fintoolbench-evaluating-llm-agents-real-world-financial-tool-use" class="img_ev3q"></p>
<p>Jiaxuan Lu와 동료들은 FinToolBench(arXiv:2603.08262, 2026년 3월)를 금융 도구 학습 에이전트를 평가하기 위한 최초의 실제 실행 가능한 벤치마크로 소개했습니다. 이 논문의 프레임워크는 명확합니다. 기존의 금융 AI 평가는 문서에 대한 정적인 질의응답(QA)에 집중하는 반면, ToolLLM과 같은 일반적인 도구 사용 벤치마크는 금융을 도메인 특화된 규정 준수 제약이 없는 일반적인 API 카테고리 중 하나로 취급한다는 것입니다. FinToolBench는 이 두 가지 한계 사이의 공백을 메우고자 합니다.</p>
<p>이 벤치마크는 760개의 실행 가능한 금융 도구(RapidAPI의 261개 실시간 엔드포인트와 AkShare의 499개 인터페이스)를 295개의 엄격하게 선별된 평가 쿼리와 결합합니다. 쿼리는 166개의 단일 도구 사례와 129개의 다중 도구 사례로 나뉩니다. 도구는 주식, 채권, 펀드, 외환, 파생상품, 거시 경제 및 암호화폐 도메인을 포괄합니다. 중요한 점은 이것들이 모의(mocked) 스텁이 아니라 실제로 호출 가능한 API라는 것입니다. 저자들은 또한 BGE-M3 검색(상위 20개 후보), 금융 속성이 주석으로 달린 도구 카드, 5단계로 제한된 제약 인식 ReAct 플래너를 사용하는 베이스라인 에이전트인 FATR(Finance-Aware Tool Routing)을 도입했습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-개념">주요 개념<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/05/fintoolbench-evaluating-llm-agents-real-world-financial-tool-use#%EC%A3%BC%EC%9A%94-%EA%B0%9C%EB%85%90" class="hash-link" aria-label="주요 개념에 대한 직접 링크" title="주요 개념에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>실행이 병목 현상이 아니라, 출력에 대한 추론이 핵심입니다.</strong> GPT-4o는 가장 높은 조건부 소프트 점수(CSS = 0.670)를 기록했는데, 이는 도구 호출에 성공했을 때 정확한 답변을 제공한다는 의미입니다. 하지만 실제 도구 호출 횟수는 22.7%(TIR = 0.227)에 불과했습니다. 반면 Qwen3-8B는 87.1%의 확률로 도구를 호출했지만, 성공 시 정답률은 40.4%에 그쳤습니다.</li>
<li class=""><strong>의도 불일치(Intent mismatch)가 주요 규정 준수 실패 원인입니다.</strong> IMR(의도 불일치율)은 대부분의 모델에서 50%를 초과했습니다. 이는 에이전트가 단순한 정보 조회를 요청받았음에도 일상적으로 트랜잭션 의도가 포함된 호출을 실행함을 의미합니다. 이는 규제가 심한 금융 환경에서 심각한 문제입니다.</li>
<li class=""><strong>금융 속성 주입은 기능 저하 없이 규정 준수를 돕습니다.</strong> 각 도구에 시의성, 의도 유형, 규제 도메인을 주석으로 추가한 FATR 베이스라인의 도구 카드는 호출률을 크게 떨어뜨리지 않으면서도 오래된 데이터 호출(TMR)과 도메인 위반(DMR)을 줄였습니다.</li>
<li class=""><strong>다중 도구 쿼리는 신뢰성 격차를 드러냅니다.</strong> 129개의 다중 도구 쿼리는 호출을 체이닝하고 단계 간에 출력을 전달해야 합니다. 성능은 단일 도구 사례에 비해 상당히 떨어졌으며, 이는 FinTrace 및 TheAgentCompany의 연구 결과와 일치합니다.</li>
<li class=""><strong>소형 모델은 호출 능력은 뛰어나지만 대형 모델만큼 추론하지 못합니다.</strong> Qwen3-8B의 TIR 0.871 대 GPT-4o의 0.227은 소형 모델이 더 "성급하게" 호출함을 보여줍니다. 그러나 Qwen3-8B의 CER(조건부 실행률, 즉 TESR/TIR) 0.339 대 GPT-4o의 0.618은 GPT-4o가 도구를 호출하기로 결정했을 때 훨씬 더 정밀하다는 것을 보여줍니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-한계점">유효한 점과 한계점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/05/fintoolbench-evaluating-llm-agents-real-world-financial-tool-use#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%ED%95%9C%EA%B3%84%EC%A0%90" class="hash-link" aria-label="유효한 점과 한계점에 대한 직접 링크" title="유효한 점과 한계점에 대한 직접 링크" translate="no">​</a></h2>
<p>진정으로 실시간으로 실행 가능한 API를 사용하기로 한 선택이 이 벤치마크의 가장 큰 기여이며 실질적인 성과입니다. 모의 API는 도구 사용 벤치마크의 고질적인 문제였습니다. ToolLLM의 16,000개 API는 인상적으로 들리지만, 실상은 LLM이 호출이 "작동했을 것인지"를 판단하는 방식입니다. FinToolBench는 이러한 문제를 피했습니다.</p>
<p>규정 준수 지표(TMR, IMR, DMR)는 개념적으로 올바릅니다. 금융 에이전트는 어제의 종가를 가져오는 것과 거래를 시작하는 것의 차이를 알아야 합니다. 하지만 이러한 분류가 어떻게 강제되는지에 대한 논문의 설명은 다소 부족합니다. 의도 유형(정보형 vs 트랜잭션형)에 대한 정답 라벨이 법률 또는 규정 준수 전문가에 의해 검증된 것인지, 아니면 단순히 데이터셋 작성자에 의해 할당된 것인지가 불분명합니다. 이는 실제 적용 시 매우 중요한 문제입니다.</p>
<p>테스트된 모델 목록도 이상하게 좁습니다. Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash 및 GPT-4o뿐입니다. 당연히 비교 대상이 되었어야 할 Claude Sonnet이나 Gemini 2.5가 빠져 있습니다. 결과 표를 보면 GPT-4o는 정밀도는 높지만 커버리지가 낮은 특이치로 나타납니다. Claude의 도구 사용 동작이 GPT-4o의 보수적인 패턴에 가까운지, 아니면 Qwen3-8B의 공격적인 패턴에 가까운지 확인하고 싶어집니다.</p>
<p>295개의 쿼리 평가 세트는 현대 벤치마크 기준으로는 작습니다. 760개의 도구가 있음을 고려할 때, 295개의 쿼리 커버리지는 대부분의 도구가 테스트되지 않았음을 의미합니다. 논문은 도메인별 커버리지 통계를 보고하지 않았으며, 이는 전체 수치가 주식이나 거시 경제와 같이 커버리지가 잘 된 일부 도메인에 의해 좌우되었을 수 있음을 시사합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai-및-beancount에-주는-시사점">금융 AI 및 Beancount에 주는 시사점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/05/fintoolbench-evaluating-llm-agents-real-world-financial-tool-use#%EA%B8%88%EC%9C%B5-ai-%EB%B0%8F-beancount%EC%97%90-%EC%A3%BC%EB%8A%94-%EC%8B%9C%EC%82%AC%EC%A0%90" class="hash-link" aria-label="금융 AI 및 Beancount에 주는 시사점에 대한 직접 링크" title="금융 AI 및 Beancount에 주는 시사점에 대한 직접 링크" translate="no">​</a></h2>
<p>Beancount 라이트백(write-back) 에이전트 — <code>bean-add</code>를 호출하거나, 원장 파일을 패치하거나, <code>beanquery</code>를 수행하는 모든 에이전트 — 는 FinToolBench가 드러낸 것과 정확히 동일한 실패 모드에 직면합니다. 의도 불일치 문제는 그대로 적용됩니다. 사용자가 읽기 질문을 했을 때 쓰기 호출을 실행하는 Beancount 에이전트는 IMR 위반과 동일한 실패 징후를 보입니다. 시의성 차원은 사용자가 현재 잔액을 기대할 때 오래된 캐시 원장 상태를 호출하는 문제와 연결됩니다.</p>
<p>정밀도 대 커버리지의 긴장 관계(GPT-4o vs Qwen3-8B) 또한 직접적인 관련이 있습니다. Beancount 쓰기 작업의 경우, 잘못된 도구를 자주 실행하는 호출률 높은 모델보다는 TIR은 낮더라도 CER과 CSS가 높은 GPT-4o의 보수적인 호출 동작이 훨씬 낫습니다. 잘못된 기록(False writes)은 아무 작업도 하지 않는 것(no-ops)보다 훨씬 더 큰 비용을 초래하기 때문입니다.</p>
<p>모델이 스스로 추론하게 하기보다 도구에 규정 준수 속성을 주석으로 다는 FATR 접근 방식은 채택할 가치가 있는 설계 패턴입니다. Beancount CLI 도구를 래핑할 때 호출이 읽기 전용인지 수정 중인지, 그리고 현재 원장 상태를 건드리는지 아니면 아카이브된 원장 상태를 건드리는지에 대한 명시적인 메타데이터를 제공하는 것은 동일한 아이디어를 더 작은 범위에 적용한 것입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음-읽을거리">다음 읽을거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/05/fintoolbench-evaluating-llm-agents-real-world-financial-tool-use#%EB%8B%A4%EC%9D%8C-%EC%9D%BD%EC%9D%84%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="다음 읽을거리에 대한 직접 링크" title="다음 읽을거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>FinTrace</strong> (arXiv:2604.10015) — 34개 금융 작업 카테고리에 걸쳐 9개 지표로 궤적 수준의 평가를 수행합니다. FinToolBench의 단일 호출 평가를 다단계 시퀀스로 직접 확장하며, 중간 추론을 개선하기 위해 DPO로 Qwen-3.5-9B를 미세 조정합니다.</li>
<li class=""><strong>FinMCP-Bench</strong> (arXiv:2603.24943) — 65개의 MCP 기반 금융 도구에 대해 613개의 샘플을 사용하여 단일 도구, 다중 도구 및 다중 턴 호출을 테스트합니다. MCP 프레임워크는 Beancount 도구 인터페이스와 직접적인 관련이 있습니다.</li>
<li class=""><strong>ToolLLM</strong> (arXiv:2307.16789, ICLR 2024) — FinToolBench가 명시적으로 대조군으로 삼은 ToolBench 논문입니다. 모의 API 베이스라인이 측정할 수 있는 것과 없는 것을 이해하면 FinToolBench의 실행 가능성이 실제로 어떤 가치를 갖는지 명확해집니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Automation" term="Automation"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Fintech" term="Fintech"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Compliance" term="Compliance"/>
        <category label="Data Science" term="Data Science"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[OmniEval: 금융 도메인을 위한 전방위적 RAG 평가 벤치마크]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/04/omnieval-omnidirectional-automatic-rag-evaluation-financial-domain</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/04/omnieval-omnidirectional-automatic-rag-evaluation-financial-domain"/>
        <updated>2026-07-04T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[OmniEval(EMNLP 2025)은 11,400개의 자동 생성된 테스트 케이스를 사용하여 5가지 작업 유형 × 16가지 금융 주제에 걸쳐 RAG 시스템을 벤치마킹합니다. 최고의 시스템조차 수치 정확도가 36%에 불과하며, 이는 구조화된 금융 원장에 기록하기 전에 RAG 파이프라인에 검증 계층이 필요하다는 구체적인 증거입니다.]]></summary>
        <content type="html"><![CDATA[<p>금융 분야의 대부분의 RAG 벤치마크는 시스템이 정보를 검색하고 답변할 수 있는지 여부만을 묻습니다. 중국 인민대학교(RUC)의 Shuting Wang 등이 발표한 OmniEval(EMNLP 2025, arXiv:2412.13018)은 더 어려운 질문을 던집니다. 즉, 작업 유형과 금융 주제의 전체 매트릭스 전반에서 성능이 유지되는가 하는 것입니다. RAG 파이프라인 위에 신뢰할 수 있는 Beancount 원장 에이전트를 구축하기 전에, 금융 분야에서 RAG 실패의 형태를 파악하려는 가장 구조화된 시도이기 때문에 이 논문을 읽고 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-요약">논문 요약<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/04/omnieval-omnidirectional-automatic-rag-evaluation-financial-domain#%EB%85%BC%EB%AC%B8-%EC%9A%94%EC%95%BD" class="hash-link" aria-label="논문 요약에 대한 직접 링크" title="논문 요약에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=OmniEval%3A%20%EA%B8%88%EC%9C%B5%20%EB%8F%84%EB%A9%94%EC%9D%B8%EC%9D%84%20%EC%9C%84%ED%95%9C%20%EC%A0%84%EB%B0%A9%EC%9C%84%EC%A0%81%20RAG%20%ED%8F%89%EA%B0%80%20%EB%B2%A4%EC%B9%98%EB%A7%88%ED%81%AC" alt="2026-07-04-omnieval-omnidirectional-automatic-rag-evaluation-financial-domain" class="img_ev3q"></p>
<p>OmniEval은 두 가지 차원의 평가 그리드를 구축합니다. 5가지 작업 클래스(추출적 QA, 멀티홉 추론, 대조적 QA, 장문 QA, 대화형 QA)와 16가지 금융 주제(주식 시장, 투자 은행, 펀드, 손해보험 등)를 교차시킵니다. 그 결과 11,400개의 자동 생성된 테스트 예제, 1,700개의 인간 주석 예제, 그리고 6개의 중국 금융 데이터 소스(193,000개의 문서를 포함한 BSCF-DB, 55,000개의 FinGLM, 48,000개의 BAAI-Fin, 공식 웹 크롤링, PDF, 위키피디아 금융 콘텐츠)에서 수집된 362,000개의 문서 검색 코퍼스로 구성된 구조화된 벤치마크가 탄생했습니다. 또한 이 벤치마크에는 910개의 인간 라벨링 인스턴스로 학습된 미세 조정 LLM 평가기인 Qwen2.5-7B-Instruct가 포함되어 있으며, 정확도, 환각, 완결성, 활용도, 수치 정확도에 걸쳐 생성 품질을 점수화합니다. 이 논문은 EMNLP 2025에 게재되었습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-아이디어">주요 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/04/omnieval-omnidirectional-automatic-rag-evaluation-financial-domain#%EC%A3%BC%EC%9A%94-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="주요 아이디어에 대한 직접 링크" title="주요 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">자동 생성된 테스트 케이스는 87.47%의 인간 수용 확인을 통과했습니다. 즉, 생성된 인스턴스 8개 중 약 1개는 폐기되었다는 뜻이며, 이는 벤치마크로서 무시할 수 없는 노이즈 비율입니다.</li>
<li class="">최고의 리트리버(GTE-Qwen2-1.5B)는 자동 생성 세트에서 0.4370의 MAP와 0.4491의 MRR을 기록했습니다. 이는 테스트된 가장 강력한 리트리버를 사용하더라도 상위 랭킹 지문이 정답일 확률이 절반도 되지 않음을 의미합니다.</li>
<li class="">모든 리트리버-LLM 조합에 걸친 생성 정확도(ACC)는 0.3238에서 0.4476 사이였습니다. 즉, 가장 우수한 구성조차 질문의 절반도 맞추지 못합니다.</li>
<li class="">수치 정확도(NAC)가 가장 두드러진 발견입니다. 0.0659에서 0.3595 사이로 나타났습니다. 최고의 시스템이 금융 수치를 맞추는 확률은 약 36%이며, 최악의 시스템은 거의 0에 가깝습니다.</li>
<li class="">미세 조정된 평가기는 인간 주석과 74.4%의 일치율(κ = 0.6486)을 보였으며, 이는 55-71% 수준인 프롬프트 기반 베이스라인을 크게 상회하지만, 여전히 평가 4개 중 1개는 인간의 판단과 일치하지 않음을 의미합니다.</li>
<li class="">멀티홉 추론과 대화형 QA가 일관되게 가장 어려운 작업 클래스로 나타났습니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-부분과-그렇지-않은-부분">유효한 부분과 그렇지 않은 부분<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/04/omnieval-omnidirectional-automatic-rag-evaluation-financial-domain#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EB%B6%80%EB%B6%84%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EB%B6%80%EB%B6%84" class="hash-link" aria-label="유효한 부분과 그렇지 않은 부분에 대한 직접 링크" title="유효한 부분과 그렇지 않은 부분에 대한 직접 링크" translate="no">​</a></h2>
<p>매트릭스 평가 설계는 정말 유용합니다. 이전의 금융 벤치마크(FinanceBench, FinQA, DocFinQA)는 평가를 주로 답변 정확도라는 단일 축으로 취급하여 RAG가 실패하는 방식의 구조적 변형을 놓쳤습니다. 시스템이 추출적 QA에서는 점수가 높지만 멀티홉 추론에서는 낮다는 것을 아는 것은 실행 가능한 정보입니다. 단순히 종합 평균 점수를 아는 것과는 다릅니다. OmniEval 그리드는 이러한 변동성을 가시화하며, 주제별로 성능이 일관되지 않다는 발견은 실무자가 배포 전에 반드시 확인해야 할 결과입니다.</p>
<p>하지만 솔직히 짚고 넘어가야 할 한계도 있습니다. 코퍼스가 압도적으로 중국어 중심입니다. 6개 데이터 소스 중 5개가 중국 금융 데이터(BSCF, FinGLM, BAAI-Fin)이고, 6번째는 중국어 위키피디아입니다. 논문은 언어별 결과를 보고하지 않고 집계된 수치만 보고합니다. 이로 인해 논문의 모든 점수는 일반적인 금융 RAG에 대한 주장이라기보다, 중국어 특화 리트리버 및 LLM(GTE-Qwen2-1.5B, Qwen2.5-72B, Yi1.5-34B)을 사용한 중국어 텍스트 기반 금융 RAG에 국한된 결과로 보일 여지가 있습니다. 영어 금융 사용자는 이 수치를 직접 활용하기 어렵습니다.</p>
<p>LLM 평가기는 910개의 라벨링된 인스턴스로 학습되었습니다. 이는 충분하지 않습니다. κ = 0.6486에서 74.4%의 인간 일치율은 시작점으로서는 방어 가능하지만, 평가 프레임워크 자체에 상당한 노이즈가 유입됨을 의미합니다. 만약 벤치마크가 단 몇 퍼센트 포인트 차이로 시스템을 비교하는 데 사용된다면, 평가기의 분산이 실제 신호를 압도할 것입니다.</p>
<p>GPT-4가 테스트 질문을 생성하고 인간이 87.47%의 수용률로 필터링하는 자동 생성 파이프라인은 논문에서 다루지 않은 오염(contamination) 문제를 야기합니다. GPT-4가 생성한 질문은 이전 모델이나 소규모 모델에 체계적으로 불리한 방식으로 GPT-4급 모델의 강점에 맞춰질 수 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="이것이-금융-ai에-중요한-이유">이것이 금융 AI에 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/04/omnieval-omnidirectional-automatic-rag-evaluation-financial-domain#%EC%9D%B4%EA%B2%83%EC%9D%B4-%EA%B8%88%EC%9C%B5-ai%EC%97%90-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="이것이 금융 AI에 중요한 이유에 대한 직접 링크" title="이것이 금융 AI에 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>제가 계속 주목하게 되는 수치는 수치 정확도 점수입니다: 0.0659–0.3595. 벤치마크 평가에서 최고의 RAG 시스템조차 금융 수치를 36%만 맞춘다면, 나이브한 RAG 파이프라인 위에 구축된 Beancount 재기록(write-back) 에이전트는 원장 데이터를 오염시킬 것입니다. Beancount 형식은 엄격합니다. 잘못된 금액, 날짜 또는 계정 이름은 파싱 오류를 일으키거나, 회계연도 전체에 전파될 수 있는 조용한 회계 오류를 만듭니다. 이 벤치마크는 RAG 검색과 LLM 생성이 검증 계층 없이는 아직 직접적인 원장 재기록을 수행하기에 충분히 신뢰할 수 없다는 구체적인 증거를 제시합니다.</p>
<p>또한 작업 클래스 구조는 Beancount 사용 사례와 깔끔하게 매칭됩니다. 추출적 QA는 단순 잔액 조회에 해당합니다. 멀티홉 추론은 "1분기부터 3분기까지 세후 순이익은 얼마인가?"와 같은 질문에 해당합니다. 대화형 QA는 사용자가 세션 전체에 걸쳐 정산 요청을 반복적으로 구체화하는 상황에 해당합니다. 멀티홉 및 대화형 작업이 가장 어렵다는 OmniEval의 발견은 Beancount 에이전트 설계에 있어 좋지 않은 소식입니다. 쉬운 케이스는 어느 정도 작동하지만, 실제적인 케이스에서 시스템이 무너진다는 뜻이기 때문입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음-읽을거리">다음 읽을거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/04/omnieval-omnidirectional-automatic-rag-evaluation-financial-domain#%EB%8B%A4%EC%9D%8C-%EC%9D%BD%EC%9D%84%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="다음 읽을거리에 대한 직접 링크" title="다음 읽을거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — OmniEval의 평가기 미세 조정 방식과 가장 유사한 일반 도메인 프레임워크입니다. ARES 방법론과 OmniEval을 비교하면 LLM 평가기 설계 선택이 원칙적인지 아니면 임시방편인지 명확히 알 수 있습니다.</li>
<li class="">RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) — RAG 평가를 위한 자동 시나리오 생성 프레임워크입니다. OmniEval이 사용하는 자동 생성 방법론을 확장하며 오염 문제를 해결할 수도 있습니다.</li>
<li class="">FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) — 시각적 인용이 포함된 멀티모달 금융 문서(표, 차트)로 RAG 평가를 확장합니다. Beancount 사용자가 일반 텍스트 원장과 함께 영수증 이미지 및 PDF 명세서를 점점 더 많이 사용하는 추세에 부합합니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="LLM" term="LLM"/>
        <category label="Finance" term="Finance"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Automation" term="Automation"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[LLM 이상 탐지 서베이 (NAACL 2025): 강력한 분류 체계, 부족한 정형 데이터 커버리지]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/03/llm-anomaly-ood-detection-survey</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/03/llm-anomaly-ood-detection-survey"/>
        <updated>2026-07-03T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Xu 및 Ding의 LLM 기반 이상 및 OOD 탐지에 관한 NAACL 2025 서베이에 대한 비판적 검토입니다. 탐지 대 생성 분류 체계는 유효하지만, 정형 데이터에 대한 설명이 거의 전무하여 금융 AI 실무자는 비전 모델의 통찰력을 직접 합성해야 합니다.]]></summary>
        <content type="html"><![CDATA[<p>이 스레드의 이전 세 게시물에서는 정형 데이터(tabular data) 이상 탐지를 구체적으로 목표로 하는 AnoLLM, CausalTAD 및 AD-LLM을 다루었습니다. NAACL 2025 Findings에 수락된 Ruiyao Xu와 Kaize Ding의 이 서베이 논문은 이러한 흐름을 하나의 통합된 지도로 묶어줄 것으로 기대되었습니다. 설계 공간을 명확히 해줄 분류 체계를 기대했지만, 제가 확인한 것은 대부분 일반론을 덧칠한 이미지 및 비디오 이상 탐지에 관한 서베이였습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-요약">논문 요약<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/03/llm-anomaly-ood-detection-survey#%EB%85%BC%EB%AC%B8-%EC%9A%94%EC%95%BD" class="hash-link" aria-label="논문 요약에 대한 직접 링크" title="논문 요약에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=LLM%20%EC%9D%B4%EC%83%81%20%ED%83%90%EC%A7%80%20%EC%84%9C%EB%B2%A0%EC%9D%B4%20%28NAACL%202025%29%3A%20%EA%B0%95%EB%A0%A5%ED%95%9C%20%EB%B6%84%EB%A5%98%20%EC%B2%B4%EA%B3%84%2C%20%EB%B6%80%EC%A1%B1%ED%95%9C%20%EC%A0%95%ED%98%95%20%EB%8D%B0%EC%9D%B4%ED%84%B0%20%EC%BB%A4%EB%B2%84%EB%A6%AC%EC%A7%80" alt="2026-07-03-llm-anomaly-ood-detection-survey" class="img_ev3q"></p>
<p>Xu와 Ding의 서베이(arXiv:2409.01980)는 LLM 기반 이상 및 분포 외(OOD) 탐지를 두 가지 상위 클래스로 구성할 것을 제안합니다. 첫 번째는 모델이 이상 징후를 직접 식별하는 **탐지를 위한 LLM(LLMs for Detection)**이고, 두 번째는 모델이 훈련 데이터를 보강하거나 하류(downstream) 탐지기에 입력될 자연어 설명을 생성하는 **생성을 위한 LLM(LLMs for Generation)**입니다. 각 클래스는 다시 세분화됩니다. 탐지는 프롬프팅 기반 방식(자연어 프롬프트로 쿼리되는 고정되거나 튜닝된 LLM)과 대조 기반 방식(이미지 패치를 텍스트 설명과 비교하여 이상 점수를 매기는 CLIP 계열 모델)으로 나뉩니다. 생성은 증강 중심 방식(의사 OOD 레이블 또는 합성 소수 샘플 생성)과 설명 중심 방식(플래그가 지정된 이벤트에 대한 자연어 근거 생성)으로 나뉩니다.</p>
<p>동반된 GitHub 읽기 목록은 약 39개의 논문을 다루고 있습니다: 탐지 24개, 증강 10개, 설명 5개입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/03/llm-anomaly-ood-detection-survey#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>대조 기반 방식이 이미지 이상 탐지를 주도하고 있습니다.</strong> WinCLIP은 데이터셋별 튜닝 없이도 MVTec-AD에서 제로샷 이상 분류 및 세분화(segmentation)에 대해 각각 91.8% 및 85.1%의 AUROC를 달성했으며, 이는 해당 데이터셋으로 학습된 지도 학습 방식과 경쟁할 수 있는 수준입니다.</li>
<li class=""><strong>고정된 LLM은 텍스트가 아닌 데이터에서 모달리티 격차(modality gap)에 부딪힙니다.</strong> 서베이는 "다양한 데이터 유형에 대해 이상 또는 OOD 탐지 결과를 얻기 위해 고정된 LLM을 직접 프롬프팅하는 것은 텍스트와 다른 데이터 모달리티 간의 내재적인 격차로 인해 종종 차선책의 성능을 낸다"고 명시적으로 언급합니다.</li>
<li class=""><strong>LoRA 및 어댑터 튜닝은 이러한 격차를 상당 부분 해소합니다.</strong> AnomalyGPT 및 AnomalyCLIP과 같은 방법은 파라미터 효율적인 기법으로 미세 조정을 수행하며, 고정된 모델보다 훨씬 뛰어난 성능을 보입니다.</li>
<li class=""><strong>증강으로서의 생성은 아직 충분히 활용되지 않고 있습니다.</strong> BLIP-2로 생성된 캡션 수준의 의사 OOD 레이블은 OOD 탐지에서 단어 수준이나 설명 수준의 대안보다 우수한 성능을 보였으며, 이는 시각적 작업에서도 더 풍부한 텍스트 감독이 중요하다는 것을 시사합니다.</li>
<li class=""><strong>설명 중심 생성은 가장 새로운 하위 범주입니다.</strong> Holmes-VAD 및 VAD-LLaMA와 같은 시스템은 단순한 이진 플래그를 넘어 주로 감시 비디오에서 발생하는 이상 이벤트에 대한 자연어 근거를 생성합니다.</li>
<li class=""><strong>정형 데이터는 거의 다뤄지지 않습니다.</strong> 이 서베이는 정형 데이터 행을 텍스트 프롬프트로 변환하고 LoRA로 미세 조정하는 Li 등(2024)의 "Tabular"라는 단 하나의 방법만을 인용하고 있으며, 비교 수치는 제공하지 않습니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/03/llm-anomaly-ood-detection-survey#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>두 가지 클래스로 나뉜 분류 체계는 정말 깔끔하며 저도 제 생각을 정리하는 데 사용할 것 같습니다. 탐지 대 생성의 구분은 실제 아키텍처의 분기점을 잘 포착하고 있습니다. LLM에 직접 분류를 요청하거나, 전통적인 탐지기를 위한 더 나은 학습 신호를 구축하는 데 LLM을 사용하는 것입니다.</p>
<p>하지만 이 논문을 광범위한 이상 탐지 서베이로 프레임화한 점은 받아들이기 어렵습니다. 다루는 내용이 산업용 결함 이미지(MVTec-AD, VisA)와 감시 비디오(UCF-Crime, XD-Violence)에 압도적으로 집중되어 있습니다. 분류된 약 39개의 논문 중 정형 데이터나 금융 데이터를 다루는 논문은 거의 없습니다. 시계열 데이터는 몇 번 인용되었고, 정형 데이터는 단 한 문장 언급됩니다. 이것은 Bean Labs를 위한 지형도가 아니라, 결함 탐지를 위해 CLIP을 사용하려는 컴퓨터 비전 연구자들을 위한 지형도입니다.</p>
<p>저자들은 "지면 제약으로 인해 상세한 지표 요약을 생략한다"고 명시했는데, 이는 비교표가 없다는 말을 정중하게 표현한 것입니다. 서베이 논문에서 정량적 합성이 없다는 것은 큰 공백입니다. 독자들은 인용된 각 논문을 개별적으로 찾아보지 않고서는 자신의 사용 사례에 어떤 패러다임이 더 나은지 이 논문을 통해 결정할 수 없습니다.</p>
<p>환각(hallucination) 문제는 향후 과제로 나열되어 있지만, 처리는 얕습니다. 어떤 탐지 패러다임이 환각에 더 취약하거나 덜 취약한지, 또는 설명 중심 생성이 인간의 검토를 통해 환각을 더 잘 발견하게 해주는지 등에 대한 분석 없이 위험성만 언급하고 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에서-이것이-중요한-이유">금융 AI에서 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/03/llm-anomaly-ood-detection-survey#%EA%B8%88%EC%9C%B5-ai%EC%97%90%EC%84%9C-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>이미지 중심의 내용임에도 불구하고 두 가지 하위 범주는 관련이 있습니다. 첫째, <strong>설명 중심 생성</strong> 하위 범주는 Beancount 감사 에이전트에게 정확히 필요한 것입니다. 단순히 회계 전표가 이상하다는 플래그를 세우는 것이 아니라, 왜 그런지 설명하는 자연어 문장이 필요합니다. 금융 감사인은 이진 출력만으로는 조치를 취할 수 없습니다. 둘째, 정형 데이터 이상 탐지에 대한 서베이의 거의 완전한 침묵은 그 자체로 시사하는 바가 큽니다. 제가 추적해 온 AnoLLM, CausalTAD, AD-LLM 흐름이 이미 잘 닦인 길이 아니라 개척 분야임을 확인시켜 줍니다. 또한 Beancount 장부를 위한 LLM 기반 감사 도구를 설계하려면 아직 정형 데이터 설정으로 이식되지 않은 비전 이상 탐지의 통찰력을 합성해야 함을 의미합니다.</p>
<p>프롬프팅 대 튜닝의 절충안이 가장 실행 가능한 발견입니다. 제로샷 프롬프팅은 1차 근사치로 작동하지만 모달리티 격차로 인해 어려움을 겪습니다. 과거 장부의 레이블이 지정된 이상 사례를 사용한 LoRA 기반 미세 조정이 그 격차를 메워줍니다. 레이블이 지정된 이상 사례가 있는 Beancount 배포의 경우, 순수 프롬프팅보다 미세 조정 경로가 더 신뢰할 수 있는 것으로 보입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음에-읽을거리">다음에 읽을거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/03/llm-anomaly-ood-detection-survey#%EB%8B%A4%EC%9D%8C%EC%97%90-%EC%9D%BD%EC%9D%84%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="다음에 읽을거리에 대한 직접 링크" title="다음에 읽을거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">"Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs" (arXiv:2406.03614) — 실제 일반 원장 회계 전표에 LLM 문장 트랜스포머 임베딩을 사용합니다. 이 서베이의 프레임워크와 Beancount 정형 데이터 사용 사례를 직접 잇는 가교 역할을 합니다.</li>
<li class="">"Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework" (arXiv:2403.19735) — 시장 데이터 이상 탐지를 위한 멀티 에이전트 파이프라인입니다. 멀티 에이전트 협업 패턴은 원장 감사로 이어질 수 있습니다.</li>
<li class="">AnomalyGPT (arXiv:2308.15366) — 픽셀 수준의 국소화(localization) 기능을 갖춘 산업용 이상 탐지를 위해 미세 조정된 LVLM입니다. 이 논문을 읽으면 서베이에서 설명은 하지만 아키텍처적으로 자세히 다루지 않은 "탐지를 위한 LLM 튜닝"이 실제로 무엇을 의미하는지 명확해집니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Fraud Detection" term="Fraud Detection"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Analytics" term="Analytics"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[중간에서 찾기: 위치적 어텐션 편향 보정을 통한 롱 컨텍스트 RAG 개선]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/02/found-in-the-middle-calibrating-positional-attention-bias</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/02/found-in-the-middle-calibrating-positional-attention-bias"/>
        <updated>2026-07-02T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[추가 학습이 필요 없는 추론 시점 보정 기술은 LLM 어텐션 가중치에서 위치적 편향을 제거하여, 검색된 문서가 컨텍스트 중간에 위치할 때 RAG 정확도를 최대 15% 포인트까지 회복시킵니다. 금융 특화 에이전트 파이프라인에 미치는 영향을 살펴봅니다.]]></summary>
        <content type="html"><![CDATA[<p>저는 Liu 등이 발견한 "중간 손실(lost-in-the-middle)" 문제에 대해 글을 쓴 이후로 줄곧 이 문제에 대해 고민해 왔습니다. LLM에 긴 컨텍스트를 전달하면 중간에 묻혀 있는 증거를 신뢰성 있게 무시한다는 내용이었죠. "중간에서 찾기: 위치적 어텐션 편향 보정을 통한 롱 컨텍스트 활용 능력 개선(Found in the Middle: Calibrating Positional Attention Bias Improves Long Context Utilization)" (Hsieh et al., ACL Findings 2024, arXiv:2406.16008)은 제가 본 것 중 가장 직접적이고 실용적인 해결책을 제시합니다. 이는 학습이 필요 없는 추론 시점 보정 기술로, 어텐션 가중치에서 모델의 위치적 편향을 빼줌으로써 RAG 정확도를 최대 15% 포인트까지 회복시킵니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-요약">논문 요약<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/02/found-in-the-middle-calibrating-positional-attention-bias#%EB%85%BC%EB%AC%B8-%EC%9A%94%EC%95%BD" class="hash-link" aria-label="논문 요약에 대한 직접 링크" title="논문 요약에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=%EC%A4%91%EA%B0%84%EC%97%90%EC%84%9C%20%EC%B0%BE%EA%B8%B0%3A%20%EC%9C%84%EC%B9%98%EC%A0%81%20%EC%96%B4%ED%85%90%EC%85%98%20%ED%8E%B8%ED%96%A5%20%EB%B3%B4%EC%A0%95%EC%9D%84%20%ED%86%B5%ED%95%9C%20%EB%A1%B1%20%EC%BB%A8%ED%85%8D%EC%8A%A4%ED%8A%B8%20RAG%20%EA%B0%9C%EC%84%A0" alt="2026-07-02-found-in-the-middle-calibrating-positional-attention-bias" class="img_ev3q"></p>
<p>Hsieh 등은 진단적 관찰에서 시작합니다. 롱 컨텍스트로 학습된 LLM이라 할지라도 지속적인 U자형 어텐션 패턴을 보인다는 점입니다. 입력의 시작과 끝에 있는 토큰은 관련성 여부와 관계없이 불균형적으로 높은 어텐션을 받는 반면, 중간에 있는 토큰은 체계적으로 과소평가됩니다. 저자들은 이를 별개의 현상으로 취급하기보다 "중간 손실"로 인한 정확도 저하와 경험적으로 연결시켰습니다.</p>
<p>그들의 해결책은 개념적으로 매우 우아합니다. 어텐션을 두 개의 가산적 구성 요소인 관련성(우리가 원하는 것)과 위치적 편향(원치 않는 것)으로 분해합니다. 편향 항을 격리하기 위해, 정보가 없는 채우기 내용인 "더미(dummy)" 문서를 각 위치의 동일한 컨텍스트에 통과시키고 그 결과로 나타나는 어텐션 분포를 기록합니다. 이 더미 문서 어텐션은 순수한 위치적 사전 확률(prior)에 근접합니다. 실제 어텐션 점수에서 이를 빼면 실제 관련성을 더 잘 반영하는 잔차가 남습니다.</p>
<p><strong>보정된 어텐션 = Attn(문서, k) − Attn(더미, k)</strong></p>
<p>이렇게 재조정된 점수는 최종 답변 생성 단계 이전에 검색된 문서를 재순위화(re-rank)하거나 가중치를 재조정하는 데 사용됩니다. 결정적으로, 추가 학습이 필요하지 않습니다. 보정은 추론 시점에 마지막 16개의 디코더 레이어와 모든 어텐션 헤드에 적용됩니다. 비용은 K가 검색된 문서의 수일 때 O(K)만큼의 추가 순전파(forward pass)가 발생하며, 이는 무시할 수 없지만 예측 가능한 수준입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/02/found-in-the-middle-calibrating-positional-attention-bias#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">U자형 어텐션 편향은 모델 아키텍처에 내재되어 있으며, 롱 컨텍스트 목적 함수로 명시적으로 학습된 모델에서도 지속됩니다.</li>
<li class="">동일한 검색 컨텍스트를 통해 더미(빈/노이즈) 문서를 통과시키면 위치적 사전 확률이 격리됩니다. 이를 빼면 미세 조정 없이도 편향을 제거할 수 있습니다.</li>
<li class="">NaturalQuestion(K=20, 정답 문서가 중간에 위치)에서의 Recall@3는 보정 후 20.52%에서 68.32%로 급증하며, K=10일 때는 36.38%에서 74.27%로 상승합니다.</li>
<li class="">정답 문서가 컨텍스트 중간에 있을 때 엔드투엔드 QA 정확도가 6~15% 포인트 향상되며, 24개의 실험 설정 중 22개에서 개선이 확인되었습니다.</li>
<li class="">이 방법은 기본 어텐션, 쿼리 생성 순위화, 관련성 생성 프롬프팅, 어텐션 정렬(Peysakhovich &amp; Lerer 2023), 프롬프트 재정렬, LongLLMLingua-rk 등 6가지 비교 기준 모델보다 우수한 성능을 보였습니다.</li>
<li class="">이 방법은 NaturalQuestion(위키피디아 기반 2,655개 실제 쿼리) 및 SynthWiki(GPT-4가 생성한 990개 합성 엔트리)에서 평가되었습니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="성과와-한계점">성과와 한계점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/02/found-in-the-middle-calibrating-positional-attention-bias#%EC%84%B1%EA%B3%BC%EC%99%80-%ED%95%9C%EA%B3%84%EC%A0%90" class="hash-link" aria-label="성과와 한계점에 대한 직접 링크" title="성과와 한계점에 대한 직접 링크" translate="no">​</a></h2>
<p>핵심 결과는 매우 인상적이며 신뢰할 만합니다. 컨텍스트 중간에 정답 문서가 있을 때 Recall@3가 20.52%에서 68.32%로 벌어지는 격차는 정밀 조사 시 사라질 숫자가 아닙니다. 이는 어텐션이 어떻게 분포되는지에 대한 실질적인 지표를 측정하고 있습니다. 학습이 필요 없는 설계는 진정한 실용적 이점입니다. 모델 가중치를 건드리지 않고도 기존의 모든 RAG 파이프라인 위에 바로 적용할 수 있기 때문입니다.</p>
<p>하지만 몇 가지 의문점도 있습니다. 첫째, "더미 문서" 접근 방식은 위치적 편향이 대략 위치별로 분리 가능하고 가산적이라고 가정하는데, 이는 저자들 스스로도 잠재적으로 너무 단순화된 선형 분해일 수 있다고 지적한 부분입니다. 실제 어텐션 편향은 콘텐츠와 비선형적인 방식으로 상호작용할 수 있습니다. 둘째, O(K)의 추가 순전파 비용을 "수용 가능한" 수준으로 평가했지만 지연 시간이나 비용에 대한 벤치마크는 수행되지 않았습니다. K=20인 운영 시스템에서 쿼리당 1번이 아닌 21번의 순전파를 실행해야 합니다. 수백 개의 트랜잭션을 분류하는 Beancount 에이전트에게 이 승수는 매우 중요합니다.</p>
<p>셋째, 가장 흥미로운 한계점인데, 저자들은 특정 작업에서는 위치적 편향이 실제로 유용할 수 있다고 언급합니다. 예를 들어, 최신성 편향(recency bias)은 모델이 오래된 항목보다 최근의 원장 항목에 올바르게 가중치를 두게 만드는 요인이 될 수 있습니다. 편향을 무차별적으로 제거하면 위치가 유효한 신호인 작업에서 손해를 볼 수 있습니다. 이 점은 인정되었지만 연구되지는 않았습니다.</p>
<p>마지막으로, 실험에는 NaturalQuestion과 합성 데이터셋이 사용되었습니다. 조밀한 표, 수년간의 공시 자료, 반복적인 구조의 원장 항목과 같은 금융 특화 문서는 범용 위키피디아 구절과는 매우 다릅니다. 이 보정 기술이 금융 RAG에서 작동할 것이라고 주장하기 전에 해당 분포에서 검증이 필요합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에서의-중요성">금융 AI에서의 중요성<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/02/found-in-the-middle-calibrating-positional-attention-bias#%EA%B8%88%EC%9C%B5-ai%EC%97%90%EC%84%9C%EC%9D%98-%EC%A4%91%EC%9A%94%EC%84%B1" class="hash-link" aria-label="금융 AI에서의 중요성에 대한 직접 링크" title="금융 AI에서의 중요성에 대한 직접 링크" translate="no">​</a></h2>
<p>직접적인 연결 고리는 분명합니다. DocFinQA 이후의 모든 기록은 동일한 문제를 맴돌고 있습니다. Beancount 에이전트가 "3월 내역을 은행 명세서와 대조해줘"와 같은 질문에 답하기 위해 20개의 관련 원장 항목을 가져올 때, 검색된 창의 중간에 있는 항목은 컨텍스트의 상단과 하단에 있는 항목에 비해 체계적으로 덜 주목받게 됩니다. 이는 검색 실패가 아니라, 아무리 검색 순위화 기능을 개선해도 해결되지 않는 생성 측면의 실패입니다.</p>
<p>"중간에서 찾기" 보정은 기본 모델의 재학습 없이도 모든 원장 QA 파이프라인의 생성 단계 내부에 직접 적용할 수 있는 그럴듯한 완화책입니다. O(K) 비용 문제는 현실적이지만 관리 가능합니다. 적당한 크기의 모델을 사용한 20개 문서 검색 창은 여전히 실용적인 범위 내에 있습니다. 실제 배포 전에 확인하고 싶은 것은 Beancount 구조의 데이터에서의 검증입니다. 위치 보정이 균일하게 도움이 되는지, 아니면 최근 트랜잭션을 과거보다 더 신뢰하게 만드는 최신성 신호를 의도치 않게 억제하는지는 확인이 필요합니다.</p>
<p>어텐션 메커니즘이 콘텐츠의 관련성과 무관하게 위치적 사전 확률을 인코딩하며, 이러한 사전 확률을 재학습 없이 보정할 수 있다는 광범위한 원칙은 기억해 둘 가치가 있습니다. 이는 토큰 빈도 편향, 입력 길이 정규화, 생성 시의 장황함 편향(verbosity bias)과 같은 다른 편향에 대한 유사한 보정의 가능성을 열어줍니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어보기">더 읽어보기<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/02/found-in-the-middle-calibrating-positional-attention-bias#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%B4%EA%B8%B0" class="hash-link" aria-label="더 읽어보기에 대한 직접 링크" title="더 읽어보기에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">"Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel" (arXiv:2406.02536, ACL Findings 2025) — 어텐션 점수를 빼는 대신 단일 은닉 상태 차원을 스케일링하는 방식을 제안합니다. "중간에서 찾기" 방식과 직접 비교해 볼 가치가 있습니다.</li>
<li class="">"Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey" (arXiv:2409.01980, NAACL 2025) — 다음 읽기 목록입니다. AnoLLM, CausalTAD, AD-LLM의 흐름을 통합된 분류 체계로 연결합니다.</li>
<li class="">Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172, TACL 2023) — "중간에서 찾기"가 대응하고자 하는 원래의 진단 연구로, 필수적인 배경 지식을 제공합니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Automation" term="Automation"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Reconciliation" term="Reconciliation"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[LLM 에이전트를 위한 불확실성 기반 위임: 소형 모델에서 대형 모델로 전환하는 시점]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/07/01/redact-uncertainty-aware-deferral-llm-agents</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/07/01/redact-uncertainty-aware-deferral-llm-agents"/>
        <updated>2026-07-01T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[ReDAct는 기본적으로 소형 모델을 실행하고 토큰 수준의 퍼플렉시티(perplexity)가 불확실성을 나타낼 때만 고가의 모델로 에스컬레이션합니다. 이를 통해 GPT-5.2 단독 사용 대비 정확도는 유지하거나 상회하면서도 64%의 비용을 절감하며, 이는 Beancount 거래 분류 에이전트에 직접 적용 가능한 패턴입니다.]]></summary>
        <content type="html"><![CDATA[<p>자율형 에이전트가 저렴하면서도 신뢰할 수 있어야 한다는 압박은 서로 상충하는 방향으로 작용합니다. 최첨단 모델은 신뢰할 수 있지만 비싸고, 소형 모델은 저렴하지만 오류가 발생하기 쉽습니다. Piatrashyn 등의 ReDAct 논문(arXiv:2604.07036)은 기본적으로 소형 모델을 실행하고 소형 모델이 불확실할 때만 대형 모델로 위임하는 중간 경로를 제안합니다. 필자가 이 논문을 읽는 이유는 모든 실무용 Beancount 라이트백(write-back) 에이전트가 동일한 딜레마를 겪기 때문입니다. 즉, 일상적인 분류는 저렴하게 처리하면서도, 장부를 오염시키기 전에 명확하지 않은 사례를 에스컬레이션하기를 원하기 때문입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-소개">논문 소개<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/01/redact-uncertainty-aware-deferral-llm-agents#%EB%85%BC%EB%AC%B8-%EC%86%8C%EA%B0%9C" class="hash-link" aria-label="논문 소개에 대한 직접 링크" title="논문 소개에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=LLM%20%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8%EB%A5%BC%20%EC%9C%84%ED%95%9C%20%EB%B6%88%ED%99%95%EC%8B%A4%EC%84%B1%20%EA%B8%B0%EB%B0%98%20%EC%9C%84%EC%9E%84%3A%20%EC%86%8C%ED%98%95%20%EB%AA%A8%EB%8D%B8%EC%97%90%EC%84%9C%20%EB%8C%80%ED%98%95%20%EB%AA%A8%EB%8D%B8%EB%A1%9C%20%EC%A0%84%ED%99%98%ED%95%98%EB%8A%94%20%EC%8B%9C%EC%A0%90" alt="2026-07-01-redact-uncertainty-aware-deferral-llm-agents" class="img_ev3q"></p>
<p>ReDAct(Reason-Defer-Act)는 ReAct 프롬프팅 패러다임을 기반으로 하며 이중 모델 에이전트 아키텍처를 도입합니다. Qwen3-80B, Llama3.3-70B 또는 Llama4-Maverick과 같은 저렴한 소형 모델이 기본적으로 모든 단계를 처리합니다. 각 단계에서 모델은 추론 과정을 생성한 다음 액션을 생성합니다. 시스템은 <em>액션 생성 단계에 대해서만</em> 토큰 수준의 불확실성을 측정하고 이를 보정된 임계값과 비교합니다. 불확실성이 임계값을 초과하면 대형 모델(GPT-5.2, Qwen3-235B 또는 Qwen3-480B)이 해당 단계를 다시 실행하고, 그렇지 않으면 소형 모델의 액션이 실행됩니다.</p>
<p>불확실성 측정은 정보 이론적이며 토큰 수준의 로그 확률(log-probabilities)만 필요로 합니다: 시퀀스 확률(음의 로그 확률 합계), 퍼플렉시티(길이 정규화됨), 평균 토큰 엔트로피(토큰 위치 전반의 평균 엔트로피). 임계값은 에피소드당 목표 대형 모델 호출 횟수 K를 생성하는 값을 선택함으로써 소형 모델 롤아웃의 홀드아웃(held-out) 세트로부터 보정됩니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-개념">주요 개념<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/01/redact-uncertainty-aware-deferral-llm-agents#%EC%A3%BC%EC%9A%94-%EA%B0%9C%EB%85%90" class="hash-link" aria-label="주요 개념에 대한 직접 링크" title="주요 개념에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>추론 단계가 아닌 액션 단계에서 불확실성을 측정하십시오.</strong> 2,411개의 ALFWorld 단계를 대상으로 한 보조 실험에서 추론 수준의 불확실성은 정답과 오답 단계를 구별하는 능력이 떨어지는 것으로 나타났습니다. 반면 액션 수준의 퍼플렉시티는 정확도의 예측 지표로서 측정 가능한 더 높은 ROC-AUC 및 PRR을 보였습니다.</li>
<li class=""><strong>Qwen3-80B + GPT-5.2를 사용한 퍼플렉시티 위임은 ALFWorld에서 80.8% ± 1.1%를 달성</strong>하여 GPT-5.2 단독(78.3% ± 1.9%) 성과를 상회하면서도 비용은 $45.21 대비 $16.25로 약 64% 저렴했습니다.</li>
<li class="">실제로는 대략 10%의 보정 목표를 맞추기 위해 <strong>약 15%의 단계가 위임됩니다.</strong> 실패한(더 짧은) 궤적이 위임 예산에 불균형적으로 기여하기 때문에 이러한 차이가 발생합니다.</li>
<li class=""><strong>동일한 비율의 무작위 위임은 77.0%를 기록했습니다.</strong> 이는 소형 모델만 사용했을 때(68.3%)보다 낫지만, 불확실성 정량화(UQ) 기반 위임보다는 낮습니다. 단순히 대형 모델을 더 많이 호출하는 것뿐만 아니라 불확실성 신호 자체가 실제로 중요합니다.</li>
<li class=""><strong>MiniGrid는 개선의 여지가 적습니다.</strong> 퍼플렉시티 위임을 사용한 Qwen3-80B + GPT-5.2는 95.0%를 기록한 반면 GPT-5.2 단독은 99.0%를 기록했습니다. 작업 어휘가 적을수록 소형 모델이 구조적으로 부적절할 때 위임 방식의 한계가 더 뚜렷해집니다.</li>
<li class=""><strong>위임 분포는 작업에 따라 다릅니다.</strong> ALFWorld는 후반 단계(프롬프트 이력이 더 긴 경우)에서 더 많이 위임하는 반면, MiniGrid는 에이전트의 초기 위치와 연관된 이봉형(bimodal) 패턴을 보입니다. 이는 고정된 임계값 보정이 작업군 내에서는 잘 일반화되지만 서로 다른 작업군 사이에서는 그렇지 않음을 의미합니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/01/redact-uncertainty-aware-deferral-llm-agents#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>핵심적인 실증 결과는 신뢰할 수 있습니다. 액션 문자열에 대한 퍼플렉시티는 특정 단계가 잘못될지 여부를 판단하는 합리적인 대리 지표입니다. ReAct의 추론/행동 분해는 불확실성 신호를 부착할 수 있는 명확한 지점을 자연스럽게 제공하며, 보조적인 정확도 예측 실험은 설계 선택에 대한 진정한 메커니즘적 근거를 제공합니다.</p>
<p>납득하기 어려운 부분은 ALFWorld에서의 "대형 모델 단독 성능 초과" 결과입니다. 80.8% ± 1.1%와 78.3% ± 1.9%는 표준 편차 범위 내에서 겹칩니다. 저자들은 이를 상호 보완적인 강점(소형 모델이 대형 모델의 가끔 발생하는 모험 없이 일상적인 단계를 처리함) 덕분이라고 주장하지만, 이 설명을 검증하기 위한 단계별 절제 실험(ablation)은 없습니다. 단순히 노이즈일 수도 있습니다.</p>
<p>벤치마크 선택도 제한적입니다. ALFWorld와 MiniGrid는 텍스트 기반의 가정 시뮬레이션 및 그리드 월드 탐색으로, 도구 호출, 코드 실행 또는 다중 문서 검색을 수행하지 않는 좁은 환경입니다. 불확실성 보정 위임이 이러한 더 풍부한 환경(Beancount와 관련된 환경)에서도 유지될지는 미지수입니다. 또한 대형 모델로 GPT-5.2를 선택한 점은 비용 수치를 재현하기 어렵게 만듭니다.</p>
<p>보정 절차에는 해결되지 않은 순환 논리가 있습니다. 임계값은 보정된 것과 동일한 분포에서 선택되며 별도의 검증 세트가 없습니다. 저자들은 보정(소형 모델 롤아웃)과 평가(하이브리드 롤아웃) 사이의 분포 변화(distribution shift)를 인정하지만, 임계값의 견고함은 향후 과제로 남겨두었습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에-이것이-중요한-이유">금융 AI에 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/01/redact-uncertainty-aware-deferral-llm-agents#%EA%B8%88%EC%9C%B5-ai%EC%97%90-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에 이것이 중요한 이유에 대한 직접 링��크" translate="no">​</a></h2>
<p>Beancount 라이트백 에이전트는 모든 거래에서 정확히 동일한 위임 문제에 직면합니다. 일상적인 식료품 구매는 분류가 필요하지만, 메모가 부분적으로만 일치하는 특이한 다단계 외화 스왑은 사람이 확인해야 합니다. 현재의 관행은 전체 자동화(위험함) 또는 전체 수동 검토(비쌈) 중 하나입니다. ReDAct의 프레임워크는 다룰 수 있는 중간 지대를 제시합니다. 즉, 저렴한 모델을 실행하고 후보 저널 엔트리(journal entry)에 대한 퍼플렉시티가 보정된 임계값을 초과할 때만 에스컬레이션하는 것입니다.</p>
<p>금융 상황에서는 논문에서 다루지 않은 두 가지 고려 사항이 추가됩니다. 첫째, 여기서의 위임은 더 큰 LLM을 호출하는 것이 아니라 <em>일시 중지하고 사용자에게 묻는 것</em>을 의미해야 합니다. 장부의 정확성 기준은 벤치마크 점수가 아니라 사용자의 의도이기 때문입니다. 둘째, 확정된 Beancount 엔트리의 비가역성은 ALFWorld에서 물건을 잘못 놓는 것보다 훨씬 높습니다. 보정 목표 K는 아마도 소형 모델의 정밀도(precision)가 낮아지기 전에 미리 위임하도록 보수적으로 조정되어야 할 것입니다.</p>
<p>이러한 주의 사항에도 불구하고 64%의 비용 절감 신호는 진지하게 받아들일 가치가 있습니다. Beancount 에이전트가 한 달 치 거래를 처리할 때 분류 결정의 15%만 고가 모델이 필요하다면, 성능이 뛰어난 라이트백 에이전트를 운영하는 경제성은 훨씬 좋아집니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어볼-거리">더 읽어볼 거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/07/01/redact-uncertainty-aware-deferral-llm-agents#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%BC-%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="더 읽어볼 거리에 대한 직접 링크" title="더 읽어볼 거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>KnowNo</strong> (Ren et al., 2023, CoRL): "도움을 요청하는 로봇: 대규모 언어 모델 플래너를 위한 불확실성 정렬" — 컨포멀 예측(conformal prediction)을 사용하여 도움을 요청할 시기에 대한 <em>커버리지(coverage)</em> 보장을 보정합니다. ReDAct는 이와 비교하지 않았는데, 프로덕션 방식을 선택하기 전에 컨포멀 보장과 임계값 보정 사이의 절충점을 이해하는 것이 중요합니다. [arXiv:2307.01928]</li>
<li class=""><strong>대규모 언어 모델의 신뢰도 추정 및 보정에 관한 설문 조사</strong> (Guo et al. updated, NAACL 2024) — 언어화된 신뢰도, 샘플링 기반 및 사후 보정 방법에 대한 체계적인 분류를 제공합니다. 퍼플렉시티가 적절한 불확실성 대리 지표인지, 아니면 보정된 로짓 스케일링(logit scaling)이 더 나은 성능을 보일지 결정하기 위한 이론적 배경입니다. [arXiv:2311.08298]</li>
<li class=""><strong>UALA: 불확실성 인지 언어 에이전트</strong> (Han, Buntine, Shareghi) — 구조적으로 유사한 불확실성 임계값을 <em>도구 호출</em> 결정(도구 사용 vs 모델 지식에 의존)에 적용하여 도구 호출을 50% 이상 줄입니다. 에이전트 불확실성의 도구 사용 축에 대해 ReDAct를 직접적으로 보완하는 연구입니다. [<a href="https://uala-agent.github.io/" target="_blank" rel="noopener noreferrer" class="">https://uala-agent.github.io/</a>]</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Automation" term="Automation"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Decision-making" term="Decision-making"/>
        <category label="Plain-Text Accounting" term="Plain-Text Accounting"/>
        <category label="Trust" term="Trust"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[OpenHands: AI 소프트웨어 에이전트를 위한 개방형 플랫폼과 금융 자동화에 시사하는 점]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/06/30/openhands-open-platform-ai-software-developers-generalist-agents</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/06/30/openhands-open-platform-ai-software-developers-generalist-agents"/>
        <updated>2026-06-30T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[OpenHands는 MIT 라이선스 기반의 Docker 샌드박스 에이전트 플랫폼으로, CodeAct가 SWE-Bench Lite에서 26%의 성능을 기록했습니다. 이는 현재 AI 에이전트가 안정적으로 수행할 수 있는 수준을 보여주는 냉정한 지표이며, 초기 금융 분야의 실질적인 배포가 자율적인 형태보다는 명확하게 정의된 범위 내에서 이루어져야 하는 이유를 설명합니다.]]></summary>
        <content type="html"><![CDATA[<p>저는 TheAgentCompany, InvestorBench 그리고 늘어나는 평가 논문들의 기저를 이루는 스캐폴딩 계층으로 OpenHands를 계속 접해 왔지만, 아직 원본 논문을 읽지는 못했습니다. 이것은 관련 분야가 조용히 구축하고 있는 인프라로서, 그 위에 구축된 개별 벤치마크 결과보다 그것이 실제로 무엇을 제공하고 어디에서 한계를 보이는지 이해하는 것이 더 중요합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-개요">논문 개요<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/30/openhands-open-platform-ai-software-developers-generalist-agents#%EB%85%BC%EB%AC%B8-%EA%B0%9C%EC%9A%94" class="hash-link" aria-label="논문 개요에 대한 직접 링크" title="논문 개요에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=OpenHands%3A%20AI%20%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%20%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8%EB%A5%BC%20%EC%9C%84%ED%95%9C%20%EA%B0%9C%EB%B0%A9%ED%98%95%20%ED%94%8C%EB%9E%AB%ED%8F%BC%EA%B3%BC%20%EA%B8%88%EC%9C%B5%20%EC%9E%90%EB%8F%99%ED%99%94%EC%97%90%20%EC%8B%9C%EC%82%AC%ED%95%98%EB%8A%94%20%EC%A0%90" alt="2026-06-30-openhands-open-platform-ai-software-developers-generalist-agents" class="img_ev3q"></p>
<p>OpenHands(Wang et al., 2024; ICLR 2025)는 범용 소프트웨어 개발자 역할을 하는 LLM 에이전트를 구축하고 평가하기 위한 오픈 소스 플랫폼입니다. Xingyao Wang과 Graham Neubig을 필두로 24명의 저자 팀이 참여한 이 논문의 핵심 주장은 기존의 에이전트 프레임워크가 연구 커뮤니티의 공통 기반으로 쓰이기에는 너무 연구 중심적이거나(하드코딩된 작업 루프), 너무 제품 중심적(폐쇄형 소스 또는 단일 목적)이라는 것입니다. OpenHands는 하나의 MIT 라이선스 저장소 아래 표준화된 런타임, 깔끔한 에이전트 추상화, 그리고 15개의 통합 평가 벤치마크를 제공함으로써 이 문제를 해결하고자 합니다.</p>
<p>런타임은 bash 쉘, Jupyter IPython 서버, Playwright로 제어되는 Chromium 브라우저를 포함하는 Docker 샌드박스 환경입니다. 에이전트는 세 가지 주요 행동 유형을 통해 상호 작용합니다: Python용 <code>IPythonRunCellAction</code>, 쉘 명령용 <code>CmdRunAction</code>, 웹 탐색용 <code>BrowserInteractiveAction</code>입니다. 다중 에이전트 협업 기본 단위인 <code>AgentDelegateAction</code>을 사용하면 메인 에이전트가 특화된 하위 에이전트를 생성할 수 있습니다. 기본 백본은 CodeAct로, 이는 원래 코드가 LLM 에이전트를 위한 이상적인 통합 행동 공간이라고 주장하는 별도의 논문으로 발표되었습니다. 플랫폼은 일반적인 CodeActAgent와 특화된 BrowsingAgent를 포함한 여러 에이전트 구현을 함께 제공합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/30/openhands-open-platform-ai-software-developers-generalist-agents#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>보편적 행동 공간으로서의 코드</strong>: CodeAct는 파일 수정, API 호출, 데이터 변환과 같은 모든 에이전트 행동을 Python 또는 bash로 통합하여, LLM이 가장 집중적으로 훈련된 매체와 동일한 방식으로 추론할 수 있게 합니다. 이는 함수 호출(function-calling) 에이전트를 괴롭히는 취약한 JSON 스키마 문제를 우회합니다.</li>
<li class=""><strong>샌드박스화된 Docker 런타임</strong>: 모든 에이전트는 격리된 컨테이너에서 실행되므로, 에이전트가 호스트 머신을 위험에 빠뜨리지 않고 임의의 코드를 자유롭게 실행할 수 있습니다. 이는 실제 자격 증명이 주어질 수 있는 상용 금융 에이전트의 필수 전제 조건입니다.</li>
<li class=""><strong>하나의 하네스에 담긴 15개 벤치마크</strong>: SWE-Bench Lite(코드 수정), HumanEvalFix(버그 수정), WebArena(웹 탐색), GPQA(대학원 수준 추론), GAIA(일반 작업 해결) 등 15개 벤치마크가 포함되어 있습니다. 이를 한곳에 모아두면 유리한 결과만 선택해서 평가하는 것을 방지할 수 있습니다.</li>
<li class=""><strong>성능 지표</strong>: CodeActAgent + claude-3.5-sonnet 조합은 SWE-Bench Lite에서 26%, HumanEvalFix에서 79.3%를 달성했습니다. BrowsingAgent는 WebArena에서 15.5%를 기록하며 특정 작업에 대한 별도 훈련 없이도 경쟁력 있는 제로샷 성능을 보여주었습니다.</li>
<li class=""><strong>GAIA 성능</strong>: GPTSwarm을 사용해 32.1%를 기록했는데, 이는 인간 기준선인 92%를 훨씬 밑도는 수치입니다. 이는 인간과 에이전트 사이에 60~70점의 격차가 있음을 보여주는 다른 일반 에이전트 벤치마크들과 일치하는 결과입니다.</li>
<li class=""><strong>커뮤니티 규모</strong>: ICLR 제출 당시 GitHub 스타 71.4K 개와 188명 이상의 기여자를 확보했습니다. TheAgentCompany가 OpenHands를 평가 하네스로 채택하면서 사실상 벤치마크 인프라로서의 지위를 얻었습니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="장점과-한계">장점과 한계<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/30/openhands-open-platform-ai-software-developers-generalist-agents#%EC%9E%A5%EC%A0%90%EA%B3%BC-%ED%95%9C%EA%B3%84" class="hash-link" aria-label="장점과 한계에 대한 직접 링크" title="장점과 한계에 대한 직접 링크" translate="no">​</a></h2>
<p>샌드박스화된 런타임 설계는 견고한 엔지니어링 결과물입니다. Docker에서 에이전트 실행을 격리하는 것은 나중에 실제 금융 원장에 대한 쓰기 권한이 부여될 수 있는 모든 시스템의 올바른 기본 설정입니다. 또한 벤치마크들이 호환되지 않는 여러 저장소에 흩어져 있지 않고 한데 모여 있다는 점은 매우 유용합니다.</p>
<p>그러나 벤치마크 범위는 체계적이라기보다는 의욕이 앞선 측면이 있습니다. 15개의 벤치마크는 결과가 어떻게 집계되거나 비교되어야 하는지에 대한 명확한 프레임워크 없이 서로 완전히 다른 작업 유형과 난이도를 포괄합니다. 동일한 논문에서 SWE-Bench Lite의 26%와 HumanEvalFix의 79.3%를 함께 보고하는 것은, 같은 에이전트가 동시에 평범하면서도 뛰어나다는 인상을 줄 위험이 있습니다. 작업 자체가 단순히 비교 불가능하기 때문입니다. 저자들은 원칙에 입각한 다중 벤치마크 통합 방법론을 제공하지 않습니다.</p>
<p>코드가 올바른 보편적 행동 형식이라는 CodeAct의 가정도 논쟁의 여지가 있습니다. 개발 작업에는 잘 작동하지만, 모든 행동에 Python/bash 중계 계층을 강제하므로 지연 시간이 추가되고 행동의 의미가 코드로 명확하게 매핑되지 않을 때(모호한 사용자 지시, 자연어 전용 API 등) 오류가 발생합니다. 이 논문은 코드 기반이 아닌 행동 공간과의 비교 벤치마크를 통해 이러한 이점이 LLM 백본에 의한 것이 아니라 실제로 존재함을 증명하지는 못했습니다.</p>
<p>가장 중요한 간극은 아마도 평가와 실제 배포 사이의 차이일 것입니다. 26%라는 SWE-Bench 수치는 상대적으로 깔끔하고 잘 정의된 벤치마크에서 나온 것입니다. 커뮤니티 보고서와 GitHub 이슈 스레드에서는 모호하거나 장기적인 실제 작업에서 훨씬 낮은 신뢰성을 일관되게 설명하고 있으며, 이는 TheAgentCompany가 기록한 실패 모드와 동일합니다. 이 논문은 현실적인 작업 사양의 노이즈 상황에서 어떻게 견고성을 측정하거나 개선할지에 대해서는 다루지 않습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai-분야에서의-의의">금융 AI 분야에서의 의의<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/30/openhands-open-platform-ai-software-developers-generalist-agents#%EA%B8%88%EC%9C%B5-ai-%EB%B6%84%EC%95%BC%EC%97%90%EC%84%9C%EC%9D%98-%EC%9D%98%EC%9D%98" class="hash-link" aria-label="금융 AI 분야에서의 의의에 대한 직접 링크" title="금융 AI 분야에서의 의의에 대한 직접 링크" translate="no">​</a></h2>
<p>OpenHands는 커뮤니티가 공유하는 에이전트 기저 계층에 가장 가까운 존재입니다. Bean Labs가 Beancount 에이전트를 위한 평가 인프라를 구축한다면, 여기서 사용된 런타임 아키텍처(Docker 샌드박스, Python/bash 행동, 교체 가능한 LLM 백엔드)는 새로 만들기보다는 채택할 가치가 충분합니다. <code>AgentDelegateAction</code> 기본 단위는 최상위 오케스트레이터가 특화된 하위 에이전트(원장 읽기용, 이상 징후 표시용, 사람이 검토할 쓰기 작업 제안용 등)에게 권한을 위임하는 금융 에이전트 파이프라인에 자연스럽게 매핑됩니다.</p>
<p>SWE-Bench와 TheAgentCompany의 수치를 종합해 보면 냉정한 사실을 알 수 있습니다. 현재 사용 가능한 최고의 에이전트조차 현실적이고 명확한 소프트웨어 작업의 약 26~30%만을 완료합니다. 금융 원장 자동화는 더 어렵습니다. 트랜잭션은 종종 모호하고, 오류의 파급 효과는 실질적이며, 사용자의 의도는 구체적이지 않은 경우가 많습니다. 여기서 얻을 수 있는 올바른 결론은 에이전트가 아직 준비되지 않았다는 것이 아니라, 초기 생산적인 배포는 자율적인 다단계 원장 수정보다는 엄격하게 범위가 제한된 단일 단계 워크플로우(분류 제안, 대조 필요 항목 표시 등)가 되어야 한다는 점입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="추천-관련-자료">추천 관련 자료<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/30/openhands-open-platform-ai-software-developers-generalist-agents#%EC%B6%94%EC%B2%9C-%EA%B4%80%EB%A0%A8-%EC%9E%90%EB%A3%8C" class="hash-link" aria-label="추천 관련 자료에 대한 직접 링크" title="추천 관련 자료에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>ReDAct: Uncertainty-Aware Deferral for LLM Agents</strong> (arXiv:2604.07036) — 저렴한 모델과 고가 모델을 쌍으로 구성하고 불확실성이 높을 때만 고가 모델에 위임합니다. OpenHands 스타일의 에이전트가 Beancount 쓰기 작업을 언제 인간 검토자에게 에스컬레이션할지 결정하는 방법을 직접적으로 다룹니다.</li>
<li class=""><strong>FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks</strong> (arXiv:2604.10015) — 34개 금융 시나리오에 걸친 800개의 전문가 주석 작업 시퀀스를 제공합니다. OpenHands가 금융 특화 장기 도구 사용에 대해 갖추지 못한 평가 방법론을 제시합니다.</li>
<li class=""><strong>FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol</strong> (arXiv:2603.24943) — 65개의 실제 MCP 금융 도구에 걸친 613개 샘플을 다룹니다. OpenHands 런타임 기반으로 구축된 Beancount 에이전트가 실제 MCP 배포 환경에서 어떻게 평가될지와 직접적인 관련이 있습니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="Open Source" term="Open Source"/>
        <category label="Automation" term="Automation"/>
        <category label="LLM" term="LLM"/>
        <category label="Developers" term="Developers"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Plain-Text Accounting" term="Plain-Text Accounting"/>
        <category label="Machine Learning" term="Machine Learning"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Fin-RATE: LLM이 기간 간 및 기업 간 재무 분석에서 실패하는 방식]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/06/29/fin-rate-real-world-financial-analytics-tracking-evaluation-benchmark</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/06/29/fin-rate-real-world-financial-analytics-tracking-evaluation-benchmark"/>
        <updated>2026-06-29T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Fin-RATE는 2,472개의 SEC 공시에서 추출한 7,500개의 전문가 큐레이션 QA 쌍을 통해 17개의 LLM을 벤치마킹하여, 시계열 추적 시 정확도가 18.60% 급락하고 금융 특화 모델인 Fin-R1의 경우 기업 간 작업에서 54포인트 하락하는 등 한계를 드러냈습니다. 또한 검색(retrieval) 파이프라인이 백본 모델보다 더 큰 병목 현상인 것으로 나타났습니다.]]></summary>
        <content type="html"><![CDATA[<p>금융 LLM 벤치마크의 궤적은 계속해서 범위를 확장하고 있으며, Fin-RATE는 모델이 실제 분석가처럼 단일 공시뿐만 아니라 여러 기간에 걸쳐, 그리고 동종 업계 경쟁사와 비교하여 기업을 추적하도록 요청받았을 때 어떤 일이 발생하는지를 보여주는 가장 명확한 사례입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문">논문<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/29/fin-rate-real-world-financial-analytics-tracking-evaluation-benchmark#%EB%85%BC%EB%AC%B8" class="hash-link" aria-label="논문에 대한 직접 링크" title="논문에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=Fin-RATE%3A%20LLM%EC%9D%B4%20%EA%B8%B0%EA%B0%84%20%EA%B0%84%20%EB%B0%8F%20%EA%B8%B0%EC%97%85%20%EA%B0%84%20%EC%9E%AC%EB%AC%B4%20%EB%B6%84%EC%84%9D%EC%97%90%EC%84%9C%20%EC%8B%A4%ED%8C%A8%ED%95%98%EB%8A%94%20%EB%B0%A9%EC%8B%9D" alt="2026-06-29-fin-rate-real-world-financial-analytics-tracking-evaluation-benchmark" class="img_ev3q"></p>
<p>2026년 2월 예일 대학교의 Yidong Jiang, Junrong Chen 및 협력 기관 연구진이 발표한 Fin-RATE는 2020년부터 2025년 사이의 43개 기업, 36개 산업 분야에 걸친 2,472개의 SEC 공시를 바탕으로 구축된 벤치마크를 소개합니다. 이 벤치마크는 전문 분석가의 워크플로우를 반영하는 세 가지 작업 유형으로 구성된 7,500개의 전문가 큐레이션 QA 쌍으로 이루어져 있습니다. 세 가지 작업은 DR-QA(단일 공시 내 세부 사항 및 추론), EC-QA(공통 주제에 대한 두 기업 간의 비교), LT-QA(보고 기간에 따른 동일 기업의 시계열 추적)입니다. 각 작업 유형은 2,500개의 질문을 포함합니다. 평가는 GPT-4.1 및 GPT-5를 포함한 폐쇄형 소스 모델, DeepSeek-V3 및 Llama-3.3-70B와 같은 오픈 소스 범용 모델, Fin-R1, Fino1-14B, FinanceConnect-13B, TouchstoneGPT-7B와 같은 금융 특화 모델 등 총 17개의 LLM을 대상으로 진행되었습니다. 점수 산정에는 통합 LLM-as-Judge 프레임워크를 사용하며, 세 명의 독립적인 평가자(GPT-5, DeepSeek-V3.2, Qwen3-235B)가 각 응답의 정확성과 5가지 분석 차원을 평가합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/29/fin-rate-real-world-financial-analytics-tracking-evaluation-benchmark#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">작업의 복잡성이 증가함에 따라 성능이 급격히 저하됩니다. 17개 모델 평균 결과, 단일 문서 DR-QA에서 시계열 LT-QA로 넘어갈 때 정확도가 18.60% 하락했으며, DR-QA에서 기업 간 EC-QA로 넘어갈 때 14.35% 하락했습니다.</li>
<li class="">웹 검색 기능이 있는 GPT-5가 가장 우수한 성능을 보였으나, 세 가지 작업 유형 전체에서 최고 정확도는 43~44%에 불과했습니다. 이는 실제 분석가의 워크플로우를 대체하기에는 턱없이 부족한 수준입니다.</li>
<li class="">금융 특화 추론 모델인 Fin-R1은 DR-QA에서 57.48%에 도달했으나, EC-QA에서는 3.32%로 무너졌습니다. 이러한 54포인트의 하락폭은 범용 모델의 성능 저하 폭을 훨씬 상회하는 수준입니다.</li>
<li class="">RAG(검색 증강 생성) 설정에서 모든 모델의 성능은 27% 미만으로 떨어졌습니다. 이는 정답 컨텍스트(gold-context)를 제공했을 때의 최고 성능인 57.48%와 대조적이며, LLM 자체가 아닌 검색 파이프라인이 결정적인 병목 현상임을 보여줍니다.</li>
<li class="">이 논문은 환각 및 모순, 금융 특화 수치 및 의미 오류, 쿼리/컨텍스트 이해 오류, 검색 수준 실패 등 4개 카테고리에 걸친 13가지 유형의 오류 분류 체계를 제시합니다. RAG 환경의 EC-QA 작업에서 '증거 누락(Missing Evidence)'은 오류의 75.44%를 차지했습니다.</li>
<li class="">금융 특화 모델은 용어 선택은 뛰어날지라도, 복잡한 작업에서 범용 모델보다 체계적으로 높은 환각 발생률을 보였습니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/29/fin-rate-real-world-financial-analytics-tracking-evaluation-benchmark#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>세 가지 경로로 구성된 구조는 매우 잘 설계되었습니다. 대부분의 금융 벤치마크(FinQA, TAT-QA, FinanceBench)는 QA를 단일 문서 작업으로 취급합니다. Fin-RATE는 기업 간 비교와 시계열 추적을 주요 작업으로 명시적으로 모델링한 최초의 사례 중 하나이며, 그 결과 현재의 LLM이 고립된 공시 QA는 어느 정도 처리하지만, 문서, 엔티티 또는 기간을 가로질러 종합해야 하는 순간 무너진다는 근본적인 격차를 드러냈습니다.</p>
<p>Fin-R1의 성능 급락은 이 논문의 가장 놀라운 발견이며 저평가된 부분이라고 생각합니다. 단일 문서 추출에 뛰어난 금융 특화 모델이 역설적으로 스스로를 막다른 골목으로 몰아넣은 것으로 보입니다. 즉, 단일 문서 내에서 답변하는 템플릿은 학습했지만, 엔티티와 기간을 연결하는 추론 전략은 학습하지 못한 것입니다. 이는 명시적인 다중 문서 추론 감독 없이 좁은 도메인에만 미세 조정(fine-tuning)을 하는 것에 대한 구체적인 경고입니다. 모델은 "공시에서 숫자를 찾는" 얕은 패턴에 과적합(overfitting)되었을 가능성이 높으며, "이 숫자를 다른 회사의 다른 공시에 있는 동일한 숫자와 비교하라"는 식의 일반화 경로를 갖지 못한 것입니다.</p>
<p>그럼에도 불구하고 짚고 넘어가야 할 방법론적 우려 사항이 있습니다. GPT-5는 평가 대상 모델인 동시에 답변을 채점하는 세 명의 평가자 중 한 명입니다. 저자들은 개별 편향을 줄이기 위해 세 명의 평가자를 사용했지만, 가장 강력한 평가 대상 모델과 평가자가 겹치는 것은 우려스러운 부분입니다. 논문은 평가자 간 높은 일치도를 보고하고 있지만, GPT-5가 자신의 응답을 채점한 비율이나 GPT-5의 자가 평가 점수가 다른 두 평가자와 체계적으로 다른지 여부를 별도로 정량화하지 않았습니다. 자가 평가 편향이 존재한다면 연구에서 가장 우수한 성능을 보인 모델의 결과가 부풀려졌을 수 있습니다.</p>
<p>43개 기업이라는 샘플 규모도 다소 작습니다. 공시 유형의 범위(10-K, 10-Q, 8-K, 6-K, DEF 14A 및 여러 S 및 SC 시리즈)는 칭찬할 만하지만, 모든 작업에 동일한 43개 기업이 등장합니다. 사전 학습(pre-training) 단계에서 이러한 기업의 공시를 본 적이 있는 모델은 수치화되지 않은 이점을 갖게 되며, 논문에는 데이터 오염(contamination) 분석이 포함되어 있지 않습니다.</p>
<p>검색(retrieval) 관련 발견은 중요하지만 불완전합니다. 논문은 검색 실패로 인해 RAG 성능이 정답 컨텍스트 대비 약 30포인트 하락한다는 점을 식별했습니다. 하지만 단일 검색 설정만 벤치마킹했을 뿐, 검색 실패를 체계적으로 변화시켜야 할 변수가 아닌 진단 결과로만 취급했습니다. Fin-RATE에서 다양한 검색 아키텍처를 훑어보는 후속 연구가 나온다면 훨씬 더 실용적일 것입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에-이것이-중요한-이유">금융 AI에 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/29/fin-rate-real-world-financial-analytics-tracking-evaluation-benchmark#%EA%B8%88%EC%9C%B5-ai%EC%97%90-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>Beancount 장부 감사는 Fin-RATE가 제대로 작동하지 않는다고 밝힌 바로 그 두 가지 기능, 즉 시계열 추적(이 계정이 회계 연도에 따라 어떻게 진화했는가?)과 엔티티 간 비교(이 자회사의 대차대조표가 연결 재무제표와 일치하는가?)를 정확히 필요로 합니다. 시계열 추적 시 18.60%의 정확도 하락은 여러 보고 기간에 걸쳐 추론하는 Beancount 에이전트에 대한 기대치를 조정해야 하는 구체적인 수치입니다. 최첨단 모델이 정답 컨텍스트가 주어진 시계열 SEC QA에서도 43%의 성공률에 그친다면, 수년간의 장부 기록을 탐색하는 Beancount 에이전트는 엔드-투-엔드 LLM 추론이 아니라 명시적인 검색, 시간적 근거 제시(temporal grounding), 그리고 인간의 개입을 염두에 두고 설계되어야 합니다.</p>
<p>검색 성능이 지배적이라는 발견은 시스템 설계 우선순위에 있어 매우 중요합니다. 정답 컨텍스트에서의 성능이 RAG 성능의 거의 두 배라면, 더 성능 좋은 백본 LLM보다는 더 나은 청킹(chunking), 구절 선택(passage selection), 검색 기술에 투자하는 것이 옳습니다. 이는 DocFinQA가 긴 컨텍스트의 SEC 공시에 대해 발견한 것과 맥을 같이 합니다. 즉, 모델을 둘러싼 파이프라인이 병목 현상이라는 것입니다.</p>
<p>Fin-R1에 대한 경고는 Beancount 사용 사례에도 직접 적용됩니다. Beancount DSL 구문과 거래 패턴에 대해 미세 조정을 하면 단순한 항목 생성은 잘 처리하는 모델이 만들어질 수 있지만, 감사를 유용하게 만드는 다중 계정, 다중 기간 대조 작업에서는 무너질 수 있습니다. 다중 문서 추론 훈련이 없는 특화는 Fin-RATE가 측정한 방식대로 취약할 수밖에 없습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음-읽을거리">다음 읽을거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/29/fin-rate-real-world-financial-analytics-tracking-evaluation-benchmark#%EB%8B%A4%EC%9D%8C-%EC%9D%BD%EC%9D%84%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="다음 읽을거리에 대한 직접 링크" title="다음 읽을거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">Fin-R1 (arXiv:2503.16252) — 어떤 학습 설정이 그렇게 취약한 교차 문서 성능을 낳았는지, 그리고 다중 문서 추론이 고려 대상이었는지 이해하기 위해.</li>
<li class="">FinTrace (arXiv:2604.10015) — 34개 금융 작업 카테고리에 걸친 LLM 도구 호출의 궤적 수준 평가. Fin-RATE의 정적 QA 관점을 보완하여 모델이 올바른 도구를 호출하면서도 결과에 대해 추론하지 못하는 지점을 진단합니다.</li>
<li class="">OpenHands (arXiv:2407.16741) — TheAgentCompany 평가의 기반이 되는 오픈 에이전트 플랫폼. 이 플랫폼의 아키텍처를 이해하면 어떤 기본 에이전트 기능이 사용 가능했는지, 그리고 어떤 격차가 플랫폼의 한계가 아닌 작업의 난이도 때문인지 명확해집니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="LLM" term="LLM"/>
        <category label="AI" term="AI"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Analytics" term="Analytics"/>
        <category label="Financial Reporting" term="Financial Reporting"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Reconciliation" term="Reconciliation"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[FinDER: 실제 분석가 쿼리를 통해 드러난 금융 RAG의 74% 재현율 격차]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/06/28/finder-financial-dataset-rag-evaluation</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/06/28/finder-financial-dataset-rag-evaluation"/>
        <updated>2026-06-28T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[FinDER는 S&P 500 10-K 공시 자료를 대상으로 5,703개의 실제 헤지펀드 분석가 쿼리를 사용하여 RAG를 벤치마킹합니다. E5-Mistral은 단 25.95%의 컨텍스트 재현율을 기록했으며, 약어가 많은 쿼리는 정밀도를 8.2포인트 떨어뜨렸습니다. 이는 더 나은 임베딩보다 쿼리 정규화가 금융 AI 파이프라인의 최우선 과제임을 시사합니다.]]></summary>
        <content type="html"><![CDATA[<p>FinDER(arXiv:2504.15800)는 단순하지만 간과되기 쉬운 관찰 결과를 바탕으로 구축된 검색 벤치마크입니다. 실제 금융 전문가들이 입력하는 쿼리는 학술적 벤치마크에 등장하는 정제된 질문과는 전혀 다르다는 점입니다. 제가 이 논문을 읽는 이유는 금융 AI의 검색 격차와 DocFinQA 및 FinanceBench가 드러내기 시작한 실제 현장의 현실성 문제라는 두 가지 맥락이 맞닿아 있기 때문입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-소개">논문 소개<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/28/finder-financial-dataset-rag-evaluation#%EB%85%BC%EB%AC%B8-%EC%86%8C%EA%B0%9C" class="hash-link" aria-label="논문 소개에 대한 직접 링크" title="논문 소개에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=FinDER%3A%20%EC%8B%A4%EC%A0%9C%20%EB%B6%84%EC%84%9D%EA%B0%80%20%EC%BF%BC%EB%A6%AC%EB%A5%BC%20%ED%86%B5%ED%95%B4%20%EB%93%9C%EB%9F%AC%EB%82%9C%20%EA%B8%88%EC%9C%B5%20RAG%EC%9D%98%2074%25%20%EC%9E%AC%ED%98%84%EC%9C%A8%20%EA%B2%A9%EC%B0%A8" alt="2026-06-28-finder-financial-dataset-rag-evaluation" class="img_ev3q"></p>
<p>최찬열, 권지훈 및 금융 AI 기업의 동료들은 실제 헤지펀드 분석가 Q&amp;A 서비스에서 추출한 5,703개의 전문가 주석 쿼리-증거-답변 삼중항 데이터셋을 제시합니다. 문서는 SEC EDGAR에서 수집한 S&amp;P 500 기업 490곳의 10-K 공시 자료입니다. FinDER가 이전 벤치마크와 구별되는 점은 쿼리 측면입니다. 쿼리의 89.86%가 3개 이상의 도메인 특화 약어나 두문자어를 포함하고 있습니다. "2023 회계연도 X 회사의 총 매출은 얼마인가요?"라고 묻는 대신, 실제 분석가는 "GOOGL 10-K FY23 revs breakdown by segment(부문별 매출 내역)"와 같이 입력할 수 있습니다. 이 데이터셋은 ICLR 2025 금융 AI 발전 워크숍(Workshop on Advances in Financial AI)에서 발표되었으며, 이후 ICAIF 2025에 게재되었습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/28/finder-financial-dataset-rag-evaluation#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>전반적으로 검색 재현율이 충격적일 정도로 낮습니다</strong>: E5-Mistral(최고 성능의 밀집 검색기)은 전체적으로 25.95%의 컨텍스트 재현율만을 기록했으며, BM25는 11.68%에 그쳤습니다. 회계와 가장 직접적으로 관련된 "Financials(재무)" 카테고리가 가장 어려웠으며, 각각 15.84%와 6.42%를 기록했습니다.</li>
<li class=""><strong>쿼리의 모호성만으로도 정밀도가 8.2포인트 하락합니다</strong>: 저자들이 500개의 쿼리에 대해 E5-Mistral을 테스트한 결과, 잘 구성된 패러프레이즈(정밀도 33.9)와 실제 약어 쿼리(정밀도 25.7)를 비교했습니다. 이 격차는 문서의 복잡성이 아니라 전적으로 약어/두문자어 처리 능력에서 기인합니다.</li>
<li class=""><strong>검색 품질이 생성의 지배적인 병목 현상입니다</strong>: 컨텍스트가 없는 LLM은 거의 0점에 가까운 점수(9<del>10% 정답률)를 기록했습니다. 상위 10개의 검색된 구절을 제공하면 29</del>34%로 올라가며, 완벽한 정답 컨텍스트(oracle context)를 제공하면 60~68%로 급증합니다. 실제 상황과 오라클 조건 사이의 35포인트 격차는 오픈 소스 모델과 프런티어 모델 간의 격차보다 더 큽니다.</li>
<li class=""><strong>구성적 산술(Compositional arithmetic)은 우수한 검색 성능에도 불구하고 한계를 보입니다</strong>: 다단계 계산 작업(구성적 쿼리)은 Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill, Qwen-QWQ 등 네 가지 모델 모두에서 상위 10개 검색 구절을 제공하더라도 약 20%의 정확도에 불과했습니다. GPT-o1은 곱셈 작업에서 42.90%로 앞서 나갔지만, 나눗셈에서는 27.78%로 떨어졌습니다.</li>
<li class=""><strong>LLM 재순위화(reranking)는 작지만 꾸준한 개선을 가져옵니다</strong>: 모델이 답변하기 전에 E5-Mistral의 상위 10개 결과에 대해 재순위화를 수행하도록 했을 때, Claude-3.7-Sonnet은 63.05, GPT-o1은 62.90의 F1 점수를 기록했습니다. Deepseek-R1-Distill은 다른 분야의 구조적 추론에서 강점을 보였음에도 불구하고 60.01로 뒤처졌습니다.</li>
<li class=""><strong>카테고리별 난이도가 불균형합니다</strong>: 리스크(Risk) 관련 쿼리는 검색이 가장 쉬웠으며(E5-Mistral 재현율 33.07), 재무(Financials)는 여전히 가장 어려웠습니다(15.84). 이는 쿼리 구조와 상관관계가 있는데, 리스크 공시는 자연어 산문 형태를 띠는 반면 재무 표는 밀도 높은 숫자 표기법을 사용하기 때문입니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/28/finder-financial-dataset-rag-evaluation#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>핵심적인 기여는 확실합니다. 현직 분석가들의 실제 쿼리 분포를 다루고 있으며, 약어 문제가 실질적이라는 점을 보여주었습니다. 위키피디아나 FinQA 스타일의 크라우드소싱으로 구축된 벤치마크는 이 점을 놓치고 있습니다. '컨텍스트 없음', '실제 검색', '오라클 컨텍스트'라는 3단계 평가 구조는 올바른 설계입니다. 이는 검색 품질과 추론 품질을 깔끔하게 분리하며, 질적인 질문에서 완벽한 컨텍스트가 주어져도 여전히 <del>32</del>34%의 실패율이 발생하는 잔여 생성 격차를 보여줍니다.</p>
<p>논문의 가장 취약한 점은 재현성입니다. 출판 당시 데이터셋이 공개되지 않았으며, 저자들은 "추후 공개할 계획"이라고만 밝혔습니다. 평가 표준을 제시하는 워크숍 논문으로서는 중대한 문제입니다. 공개되지 않은 벤치마크는 벤치마크가 아니라 사례 연구일 뿐입니다. 이후 ICAIF 2025에 등장했으므로 출시되었을 가능성도 있지만, arXiv 버전에서는 이를 확인할 수 없습니다.</p>
<p>또한 검색 평가는 네 가지 단일 단계 모델(BM25, GTE, mE5, E5-Mistral)만을 사용했습니다. 하이브리드 검색, 쿼리 확장, HyDE, 약어 문제를 구체적으로 겨냥한 재작성(rewriting) 단계도 없었습니다. 저자들이 약어 격차를 정확히 규정했다는 점을 고려하면, 검색 전 쿼리 확장("GOOGL" → "Alphabet Inc.")과 같은 명백한 해결책을 테스트하지 않은 것은 의외입니다. 해당 실험은 누락되었습니다.</p>
<p>생성 결과는 더 자세히 살펴볼 가치가 있습니다. 컨텍스트가 없을 때의 <del>9</del>10% 성능은 유용한 하한선이 아니라 사실상 0에 가깝지만, 60~68%의 오라클 상한선은 보기보다 더 많은 정보를 줍니다. 올바른 구절이 주어져도 최고 성능의 모델들이 정성적 질문의 약 1/3, 구성적 산술의 4/5에서 실패한다는 것을 의미합니다. 이 상한선은 중요합니다. 즉, 검색만으로는 문제를 해결할 수 없음을 뜻합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에서-이것이-중요한-이유">금융 AI에서 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/28/finder-financial-dataset-rag-evaluation#%EA%B8%88%EC%9C%B5-ai%EC%97%90%EC%84%9C-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>FinDER의 쿼리 분포는 Beancount 사용자가 원장 에이전트와 실제로 상호작용하는 방식과 잘 맞아떨어집니다. 수년간 계정을 관리해 온 사용자는 "아마존 신용카드 3분기 환급액이 얼마인가요?"라고 묻기보다 "AMZN card Q3 reimb?"와 같이 축약된 문맥적 쿼리를 입력할 것입니다. 표준 임베딩 모델은 정제된 자연어 텍스트로 훈련되었기 때문에 올바른 항목을 검색하는 데 실패할 것입니다. 정제된 쿼리에서 실제 쿼리로 넘어갈 때 발생하는 8.2포인트의 정밀도 하락은 개인 원장 도메인에서는 오히려 보수적인 수치일 수 있습니다. 개인적인 약어(예: "property management fee" 대신 "prop mgmt fee")는 SEC 표준 약어보다 훈련 데이터에서 더 멀리 떨어져 있기 때문입니다.</p>
<p>E5-Mistral의 25.95% 컨텍스트 재현율 상한선은 강제적인 제약 조건이 됩니다. 모든 Beancount RAG 파이프라인은 상당 부분의 증거를 놓칠 가능성에 대비해야 합니다. 한 가지 시사점은 단일 패스에서 F1 점수를 올리는 것보다 높은 재현율을 위한 재검색(다중 패스, 다양한 쿼리 구성)이 더 중요하다는 것입니다. 또 다른 시사점은 검색 전 사용자 약어를 표준 계정 이름으로 매핑하는 쿼리 정규화가 임베딩 모델에 맡겨둘 것이 아니라 명시적인 전처리 단계가 되어야 한다는 점입니다.</p>
<p>오라클 컨텍스트에서도 20%에 불과한 구성적 산술 정확도는 별도의 신호를 보냅니다. Beancount 계산 작업의 경우 생성 병목 현상은 검색이 아니라 추론에 있습니다. 숫자 관련 작업에서는 검색 성능이 아무리 좋아지더라도 PAL 방식의 오프로딩(자유 형식 텍스트 계산 대신 Python 산술 코드를 생성하는 방식)이 여전히 올바른 해답입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어볼-거리">더 읽어볼 거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/28/finder-financial-dataset-rag-evaluation#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%BC-%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="더 읽어볼 거리에 대한 직접 링크" title="더 읽어볼 거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>Fin-RATE</strong> (arXiv:2602.07294) — SEC 공시 자료의 다기간 추적을 위한 동반 벤치마크입니다. 시계열 작업에서 정확도가 18.60% 하락하며, 이는 Beancount의 다년 원장 문제와 직결됩니다.</li>
<li class=""><strong>IRCoT</strong> (arXiv:2212.10509, ACL 2023) — 검색과 생각의 사슬(CoT) 추론을 결합하는 방식입니다. 다중 패스 검색 구조는 FinDER가 노출한 낮은 단일 패스 재현율 문제를 직접적으로 해결합니다.</li>
<li class=""><strong>LLM을 활용한 도메인 특화 검색용 쿼리 확장</strong> — 아직 이 부분을 완벽하게 다루는 단일 벤치마크 논문은 없지만, FinDER의 약어 격차는 이를 최우선 연구 과제로 만듭니다. "HyDE financial domain" 및 "query expansion SEC filings 2025"를 검색하는 것이 좋은 시작점이 될 것입니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Finance" term="Finance"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Financial Reporting" term="Financial Reporting"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Lost in the Middle: LLM의 위치 편향과 금융 AI에 미치는 영향]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/06/27/lost-in-the-middle-language-models-long-contexts</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/06/27/lost-in-the-middle-language-models-long-contexts"/>
        <updated>2026-06-27T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Liu 등이 발표한 TACL 2024 논문은 LLM이 긴 컨텍스트의 중간에 배치된 정보에 대해 성능이 최대 20포인트 하락하는 U자형 성능 저하 현상을 보여줍니다. 이는 Claude-1.3-100K를 포함한 모든 테스트 모델에서 나타나며, 금융 및 회계 애플리케이션의 RAG 파이프라인에서 검색된 구절을 배치하는 방식에 구체적인 시사점을 제공합니다.]]></summary>
        <content type="html"><![CDATA[<p>검색 기반 파이프라인과 긴 컨텍스트 LLM 모두 123K 토큰 컨텍스트의 SEC 공시 자료에서 무너졌던 DocFinQA 사례를 되돌아볼 때, 제가 남겨두었던 질문은 '왜'였습니다. Liu 등(TACL 2024, arXiv:2307.03172)의 이 논문은 그 메커니즘에 대한 해답을 제시하며, 실패 양상이 제가 예상했던 것보다 더 단순하고 고질적이라는 사실을 보여줍니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-요약">논문 요약<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/27/lost-in-the-middle-language-models-long-contexts#%EB%85%BC%EB%AC%B8-%EC%9A%94%EC%95%BD" class="hash-link" aria-label="논문 요약에 대한 직접 링크" title="논문 요약에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=Lost%20in%20the%20Middle%3A%20LLM%EC%9D%98%20%EC%9C%84%EC%B9%98%20%ED%8E%B8%ED%96%A5%EA%B3%BC%20%EA%B8%88%EC%9C%B5%20AI%EC%97%90%20%EB%AF%B8%EC%B9%98%EB%8A%94%20%EC%98%81%ED%96%A5" alt="2026-06-27-lost-in-the-middle-language-models-long-contexts" class="img_ev3q"></p>
<p>Nelson F. Liu 등이 집필한 "Lost in the Middle: How Language Models Use Long Contexts"는 두 가지 목표 실험을 수행합니다. 하나는 NaturalQuestions-Open에 대한 다중 문서 질의응답(검색된 문서 10개, 20개, 30개 사용)이고, 다른 하나는 합성 키-값(key-value) 검색(75개, 140개, 300개 쌍 사용)입니다. 각 실험에서 연구진은 다른 모든 조건은 고정시킨 채 관련 문서나 키-값 쌍이 입력 컨텍스트의 어디(시작, 중간, 끝)에 위치하는지를 체계적으로 변화시켰습니다. 결과는 명확했습니다. 성능은 컨텍스트 중간에서 최저점을 찍는 U자형 곡선을 그리며, 이 곡선은 테스트된 모든 모델에서 나타났습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-개념">주요 개념<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/27/lost-in-the-middle-language-models-long-contexts#%EC%A3%BC%EC%9A%94-%EA%B0%9C%EB%85%90" class="hash-link" aria-label="주요 개념에 대한 직접 링크" title="주요 개념에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>U자형 현상은 실재하며 일관적입니다.</strong> 20개 문서 QA 설정에서 첫 번째 위치에서의 성능은 약 75%였으나, 10번째 위치에서는 약 55%로 저하되었다가 20번째 위치에서 다시 약 72%로 회복되었습니다. 양 끝과 중앙 사이에 약 20포인트의 격차가 발생한 것입니다.</li>
<li class=""><strong>모든 모델이 동일한 패턴을 따릅니다.</strong> 테스트된 모델은 폐쇄형과 오픈 소스, 소형과 대형을 망라합니다. GPT-3.5-Turbo(4K 및 16K), GPT-4, Claude-1.3(8K 및 100K), MPT-30B-Instruct, LongChat-13B가 포함되었습니다. 확장된 컨텍스트 창을 강점으로 내세운 모델들을 포함하여 모든 모델에서 U자형 곡선이 나타났습니다.</li>
<li class=""><strong>Claude-1.3-100K조차 예외가 아닙니다.</strong> 100K 컨텍스트 변체도 다른 모델들과 마찬가지로 동작했습니다. 긴 컨텍스트 창이 있다고 해서 모델이 실제로 그 전체를 균일하게 주의(attention) 깊게 살피는 것은 아닙니다.</li>
<li class=""><strong>폐쇄형 문서(closed-book) 기준선은 냉혹한 하한선을 제시합니다.</strong> 문서가 없는 GPT-3.5-Turbo는 NaturalQuestions의 56.1%를 맞혔고, 관련 문서 하나에만 접근할 수 있을 때는 88.3%를 기록했습니다. 그러나 20개 문서 설정의 최악인 중간 위치에서는 성능이 폐쇄형 기준선 아래로 떨어졌습니다. 즉, 컨텍스트를 더 많이 추가하는 것이 오히려 독이 된 셈입니다.</li>
<li class=""><strong>인코더-디코더 모델(Flan-T5-XXL, Flan-UL2)은 훈련 길이 내에서는 더 견고하지만, 컨텍스트가 이를 초과하면 다시 성능이 저하됩니다.</strong> 아키텍처의 차이가 영향을 미치지만, 규모가 커지면 둘 다 성능이 떨어지는 것은 마찬가지입니다.</li>
<li class=""><strong>근본 원인은 인과적 어텐션 마스킹(causal attention masking)입니다.</strong> 각 토큰은 이전 토큰에만 주의를 기울일 수 있으므로, 맨 앞의 위치는 중간 위치보다 모델 전체에서 더 많은 총 어텐션 가중치를 축적하게 됩니다. 또한 최신성 효과(recency effects)로 인해 컨텍스트의 끝부분도 주의를 더 많이 받게 됩니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/27/lost-in-the-middle-language-models-long-contexts#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>이 논문의 실험 설계는 훌륭할 정도로 깔끔합니다. 위치가 유일하게 조작된 변수이고, 작업은 표준 벤치마크이며, 결과는 광범위한 모델 제품군에서 재현되었습니다. 핵심 결과에 대해서는 이견의 여지가 없습니다.</p>
<p>다만 키-값 검색 작업을 실제 사용 사례의 유의미한 대리 지표로 설정한 프레임워크는 다소 설득력이 떨어집니다. UUID 대 UUID 조회는 모델이 암기된 문자열을 그대로 따라 할 수 있는지를 테스트하는 것이지, 추론이 필요한 작업을 수행할 수 있는지를 테스트하는 것이 아닙니다. 여기서도 U자형 곡선이 나타난다는 점은 위치 편향 주장을 강화하지만, 한편으로는 논문이 '정확한 일치(exact-match) 작업에서의 검색 정확도'와 '관련 구절에 대한 추론 품질'이라는 두 가지 서로 다른 현상을 혼동하고 있다는 의미이기도 합니다. 관련 문서가 최종 답변을 내기 전 다단계 추론을 요구할 때 U자형 곡선이 더 악화되는지 혹은 개선되는지를 알고 싶어지는 대목입니다.</p>
<p>또한 저자들이 어느 정도 인정하면서도 해결하지 못한 공백이 있습니다. 이들은 지시어 미세 조정(instruction fine-tuning)이나 RLHF가 위치 민감도를 변화시키는지 테스트하지 않았고, 단지 더 큰 컨텍스트 창의 영향만을 확인했습니다. 근본 원인이 아키텍처(인과적 마스킹)에 있다는 점을 감안할 때 지시어 튜닝이 이를 해결하지 못할 것으로 의심되지만, 논문에서 이를 확증하지는 않았습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에-이것이-중요한-이유">금융 AI에 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/27/lost-in-the-middle-language-models-long-contexts#%EA%B8%88%EC%9C%B5-ai%EC%97%90-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>이 논문은 제가 현장에서 계속 접하는 실증적 패턴에 대한 기계적인 설명을 제공합니다. DocFinQA는 긴 SEC 공시 자료에서 무너졌습니다. IRCoT와 FLARE는 모두 여러 구절을 검색하여 추론 전에 이를 연결(concatenate)합니다. 제가 살펴본 금융 컨텍스트의 모든 RAG 파이프라인은 검색된 구절을 순차적으로 프롬프트에 집어넣고 모델이 적절한 구절에 주의를 기울이기를 기대합니다.</p>
<p>Beancount 에이전트에게 주는 시사점은 구체적입니다. 에이전트가 컨텍스트로 10개의 장부 항목(ledger entries)을 가져온다면, 3~7번째 위치에 있는 항목은 무시되거나 환각(hallucination)이 발생할 위험이 가장 큽니다. 이는 검색의 문제가 아니라 제시(presentation)의 문제입니다. 이 논문으로부터 도출할 수 있는 대응책은 두 가지입니다. 가장 진단적으로 가치 있는 항목을 맨 앞(또는 맨 뒤)에 배치하거나, 아예 연결하지 않고 한 번에 하나의 구절에 대해서만 추론하게 하는 것입니다.</p>
<p>또한 이 결과는 긴 컨텍스트 LLM에 대한 서사를 복잡하게 만듭니다. 매 분기마다 새로운 모델이 더 큰 컨텍스트 창을 발표합니다. 하지만 이 논문은 증거를 컨텍스트 전체에 균등하게 분산시킨다면 창의 길이가 생각만큼 중요하지 않을 수 있다고 말합니다. 관련 거래 내역을 60K 위치에 묻어버리는 128K 컨텍스트 모델은 정확히 필요한 구절만 검색하는 4K 컨텍스트 모델보다 성능이 떨어집니다.</p>
<p>라이트백(write-back) 안정성 측면에서도 우려되는 점이 있습니다. 모델에게 장부 세션을 요약하도록 요청했는데, 관련 "이 거래를 게시하지 마시오"라는 정책 규칙이 긴 시스템 프롬프트 중간에 나타난다면, 모델은 그 규칙을 읽지 않은 것처럼 행동할 수 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어보기">더 읽어보기<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/27/lost-in-the-middle-language-models-long-contexts#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%B4%EA%B8%B0" class="hash-link" aria-label="더 읽어보기에 대한 직접 링크" title="더 읽어보기에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>"Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding"</strong> (Zhang et al., arXiv:2403.04797) — RoPE 스케일링을 통한 훈련 없는 수정안인 Ms-PoE를 제안하며, Zero-SCROLLS에서 최대 3.8포인트 개선을 통해 U자형 곡선 문제를 직접 해결한다고 주장합니다.</li>
<li class=""><strong>"Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training"</strong> (arXiv:2311.09198) — 반대의 접근 방식을 취하여 모델이 명시적으로 위치와 무관하게 학습되도록 훈련합니다. Ms-PoE와의 비교를 통해 미세 조정과 추론 시점의 기교 중 어느 것이 더 나은 수단인지 명확히 해줍니다.</li>
<li class=""><strong>"Mitigate Position Bias in Large Language Models via Scaling a Single Dimension"</strong> (arXiv:2406.02536) — 편향을 유발하는 특정 위치 숨겨진 상태(positional hidden states) 차원을 식별하고 재학습 없이 이를 스케일링합니다. 현재까지 제안된 가장 정밀한 수정 방식이며, 재학습 없이 기존 모델을 배포하는 데 유용합니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="LLM" term="LLM"/>
        <category label="AI" term="AI"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Finance" term="Finance"/>
        <category label="Technology" term="Technology"/>
        <category label="Analytics" term="Analytics"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[AD-LLM 벤치마크: GPT-4o, 텍스트 이상 탐지에서 제로샷 AUROC 0.93+ 달성]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/06/26/ad-llm-benchmarking-llms-anomaly-detection</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/06/26/ad-llm-benchmarking-llms-anomaly-detection"/>
        <updated>2026-06-26T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[AD-LLM은 5개의 NLP 데이터셋을 대상으로 제로샷 탐지기, 데이터 증강 도구, 모델 선택 조언자라는 세 가지 이상 탐지 역할에서 GPT-4o와 Llama 3.1 8B를 벤치마킹합니다. GPT-4o는 제로샷에서 0.93–0.99의 AUROC를 기록했지만, LLM 기반 모델 선택은 여전히 신뢰하기 어렵다는 점을 보여주며, 이는 금융 감사 AI에 직접적인 시사점을 제공합니다.]]></summary>
        <content type="html"><![CDATA[<p>이 시리즈의 지난 두 게시물에서는 표 형식 이상 탐지에 대한 미세 조정(fine-tuned) 및 프롬프트 엔지니어링 접근 방식인 AnoLLM과 CausalTAD를 다루었습니다. 이러한 방식들을 실제 운영 환경에 배포하기 전에, 더 넓은 범위의 이상 탐지 패러다임에서 LLM이 실제로 어느 위치에 있는지 파악해야 합니다. 이것이 바로 AD-LLM의 명시적인 목표입니다. AD-LLM은 제로샷 탐지기(zero-shot detector), 데이터 증강 엔진(data augmentation engine), 모델 선택 조언자(model selection advisor)라는 세 가지 별개의 역할에 걸쳐 LLM을 벤치마킹합니다. 비록 표 형식의 장부 항목보다는 NLP 텍스트 데이터에 초점을 맞추고 있지만, 방법론적 교훈은 그대로 전이됩니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-소개">논문 소개<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/26/ad-llm-benchmarking-llms-anomaly-detection#%EB%85%BC%EB%AC%B8-%EC%86%8C%EA%B0%9C" class="hash-link" aria-label="논문 소개에 대한 직접 링크" title="논문 소개에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=AD-LLM%20%EB%B2%A4%EC%B9%98%EB%A7%88%ED%81%AC%3A%20GPT-4o%2C%20%ED%85%8D%EC%8A%A4%ED%8A%B8%20%EC%9D%B4%EC%83%81%20%ED%83%90%EC%A7%80%EC%97%90%EC%84%9C%20%EC%A0%9C%EB%A1%9C%EC%83%B7%20AUROC%200.93%2B%20%EB%8B%AC%EC%84%B1" alt="2026-06-26-ad-llm-benchmarking-llms-anomaly-detection" class="img_ev3q"></p>
<p>USC와 Texas A&amp;M의 Tiankai Yang, Yi Nian 및 동료들은 NLP 데이터셋의 세 가지 이상 탐지 패러다임에서 LLM을 체계적으로 평가하는 최초의 벤치마크인 AD-LLM(arXiv:2412.11142, ACL Findings 2025)을 소개했습니다. 설정은 1클래스 분류(one-class classification)입니다. 즉, 훈련 데이터에는 정상 샘플만 포함되며, 모델은 테스트 시점에 이상 징후를 식별해야 합니다. 사용된 5개의 데이터셋(AG News, BBC News, IMDB Reviews, N24 News, SMS Spam)은 모두 하나의 카테고리를 이상치로 지정한 텍스트 분류 작업에서 파생되었습니다. 이 논문은 GPT-4o와 Llama 3.1 8B Instruct라는 두 가지 LLM을 엔드투엔드 방식(CVDD, DATE) 및 2단계 임베딩+탐지기 조합(OpenAI 임베딩 + LUNAR, LOF, Isolation Forest 등)을 포함하는 18개의 기존 비지도 학습 베이스라인과 비교합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="주요-개념">주요 개념<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/26/ad-llm-benchmarking-llms-anomaly-detection#%EC%A3%BC%EC%9A%94-%EA%B0%9C%EB%85%90" class="hash-link" aria-label="주요 개념에 대한 직접 링크" title="주요 개념에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>텍스트에 대한 제로샷 탐지가 효과적입니다.</strong> GPT-4o는 정상+이상 설정의 5개 데이터셋에서 0.9293–0.9919의 AUROC를 기록했으며, Llama 3.1은 0.8612–0.9487에 도달했습니다. 가장 우수한 기존 베이스라인인 OpenAI + LUNAR는 AG News에서 약 0.92를 기록했는데, GPT-4o는 훈련 없이도 이를 능가하거나 대등한 성능을 보였습니다.</li>
<li class=""><strong>합성 데이터 증강이 일관되게, 하지만 소폭으로 도움이 됩니다.</strong> LLM이 생성한 합성 샘플은 5개 데이터셋 모두에서 OpenAI + LUNAR 파이프라인을 개선했습니다. 카테고리 설명 증강 또한 대부분의 베이스라인을 개선했지만, 이득은 불균등했습니다. Llama 3.1은 IMDB Reviews에서 AUROC를 0.07 향상시켰으나 다른 곳에서는 그 효과가 더 작았습니다.</li>
<li class=""><strong>모델 선택이 취약한 고리입니다.</strong> GPT-o1-preview는 대부분의 데이터셋에서 평균 베이스라인 성능을 넘어서는 모델을 추천하며, 때때로 최상의 방식에 근접하기도 했습니다(예: IMDB Reviews 및 SMS Spam). 그러나 최고 성능의 모델을 안정적으로 식별하지는 못했으며, 저자들은 추천이 데이터셋별 통계가 부족한 단순한 입력을 기반으로 한다는 점을 인정했습니다.</li>
<li class=""><strong>오픈소스와 상용 모델 간의 격차가 실재합니다.</strong> Llama 3.1 8B에 대한 GPT-4o의 AUROC 우위는 데이터셋에 따라 4~13포인트였으며, 이는 제로샷 표 형식 이상 탐지 논문에서 보여준 패턴과 일치합니다.</li>
<li class=""><strong>NLP 이상 탐지에는 여전히 결정적인 벤치마크가 부족합니다.</strong> 분류 코퍼스에서 파생된 5개의 데이터셋은 다소 부족합니다. 자매 논문인 NLP-ADBench(EMNLP Findings 2025)는 8개의 데이터셋과 19개의 알고리즘으로 확장되었으나, 여전히 의미론적 범주를 이상치로 간주하는 구성을 사용하고 있어 이러한 작업들이 다소 인위적일 수 있습니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/26/ad-llm-benchmarking-llms-anomaly-detection#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>제로샷 결과는 신뢰할 수 있습니다. 레이블이 지정된 이상 데이터 없이 LLM을 점수 측정기로 사용하는 것은 스팸 메시지와 일반 메시지의 차이처럼 이상 범주가 의미론적으로 일관될 때 진정으로 유용합니다. 이는 잘 훈련된 언어 모델이 이해할 수 있는 방식이기 때문입니다. AUROC 수치는 높으며, 강력한 OpenAI 임베딩 기반 베이스라인과의 비교도 공정합니다.</p>
<p>하지만 논문에서 과소평가된 측면에서 그 범위가 좁습니다. 5개의 데이터셋 모두 이상치를 다른 <em>주제 카테고리</em>로 인코딩합니다(예: 스팸 대 일반 SMS, 특정 언론사 뉴스 대 분포 내 뉴스). 이는 LLM이 본질적으로 주제 분류(topic classification)를 수행하고 있음을 의미하며, 이는 LLM이 명시적으로 사전 학습된 작업입니다. 이 벤치마크는 동일한 계정 유형 내의 비정상적인 거래와 같이 단일 범주 내의 의미론적 이상치를 포함하지 않는데, 이는 금융 감사에서 정확히 중요한 종류의 이상 징후입니다.</p>
<p>데이터 증강 및 모델 선택 작업도 동일한 5개 데이터셋에서 평가되므로, 결과적으로 이 논문은 LLM이 동일한 좁은 문제의 약간 다른 측면을 아주 조금 더 낫게 만들 수 있는지 벤치마킹하는 셈이 됩니다. 저자들은 모델 선택을 위해 단순한 입력에 의존하고, 소수샷(few-shot) 및 미세 조정 방식을 제외하며, 일부 LLM만 테스트했다는 점을 포함하여 6가지 한계점을 솔직하게 나열했습니다. 이는 학술적으로 정직하지만, 이 벤치마크가 얼마나 초기 단계인지를 보여주기도 합니다.</p>
<p>회의적인 시각에서 주목할 만한 결과가 하나 있습니다. 두 모델 모두 AUPRC 점수가 AUROC보다 상당히 낮다는 점입니다. BBC News에서 Llama 3.1은 AUROC 0.8612에 도달했지만 AUPRC는 0.3960에 불과했는데, 이는 1클래스 설정에서의 클래스 불균형을 반영합니다. 높은 정밀도가 요구되는 감사 환경에서는 AUPRC가 더 의미 있는 지표이며, 이 지표로 보면 상황은 덜 낙관적입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에-이것이-중요한-이유">금융 AI에 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/26/ad-llm-benchmarking-llms-anomaly-detection#%EA%B8%88%EC%9C%B5-ai%EC%97%90-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI��에 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>Bean Labs의 아젠다에는 두 가지 이상 탐지 사용 사례가 포함됩니다. 실시간으로 비정상적인 장부 항목을 포착하는 것(표 형식, 구조화 데이터)과 송장, 메모 또는 고객 지원 티켓에서 의심스러운 서술형 텍스트를 식별하는 것(비구조화 NLP)입니다. AD-LLM은 두 번째 사례에 직접적으로 해당하며 현실적인 상한선을 제시합니다. GPT-4o는 깨끗하고 균형 잡힌 데이터셋에서 0.93 이상의 AUROC로 텍스트의 주제 수준 이상치를 제로샷으로 탐지할 수 있습니다. 이는 유용한 사전 지식이지만, 장부 적요(narrative) 이상치는 더 미묘합니다. 일상적인 서비스를 설명하지만 의심스러운 패턴으로 플래그가 지정된 공급업체에 속한 송장 메모는 주제 분류 문제가 아닙니다. 이 벤치마크는 시작점일 뿐 정답은 아닙니다.</p>
<p>모델 선택 결과는 시스템 설계 측면에서 별도로 흥미롭습니다. LLM에게 "이 데이터셋에 어떤 이상 탐지기를 사용해야 할까?"라고 묻고 신뢰할 수 있는 답변을 얻으려는 꿈은 아직 실현되지 않았습니다. 즉, AnoLLM 스타일의 미세 조정, CausalTAD 스타일의 인과 프롬프팅 또는 전통적인 임베딩 방법 중 무엇을 선택할지는 여전히 인간의 판단이나 체계적인 실증적 평가가 필요하며, 이를 LLM 조언자에게 위임할 수 없습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음-읽을거리">다음 읽을거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/26/ad-llm-benchmarking-llms-anomaly-detection#%EB%8B%A4%EC%9D%8C-%EC%9D%BD%EC%9D%84%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="다음 읽을거리에 대한 직접 링크" title="다음 읽을거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>NLP-ADBench</strong> (arXiv:2412.04784, EMNLP Findings 2025) — 같은 그룹의 자매 벤치마크로, 8개의 데이터셋과 19개의 알고리즘을 다룹니다. AD-LLM의 5개 데이터셋 규모가 제공하지 못하는 더 넓은 전통적 베이스라인 컨텍스트를 제공합니다.</li>
<li class=""><strong>Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey</strong> (arXiv:2409.01980, NAACL Findings 2025) — 텍스트, 이미지 및 표 형식 양식에 걸친 LLM 기반 이상 탐지 접근 방식의 전체 환경을 조사합니다. 이전 작업들에 비해 AD-LLM이 차지하는 위치를 보충해 줍니다.</li>
<li class=""><strong>AnoLLM: Large Language Models for Tabular Anomaly Detection</strong> (OpenReview:7VkHffT5X2, ICLR 2025) — 표 형식 데이터에 대한 대응물입니다. 이 논문의 우도 기반(likelihood-based) 접근 방식과 AD-LLM의 프롬프트 기반 제로샷 전략을 비교하면 Beancount 장부 항목에 어떤 패러다임이 더 적합한지 명확해집니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="LLM" term="LLM"/>
        <category label="AI" term="AI"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Fraud Detection" term="Fraud Detection"/>
        <category label="Analytics" term="Analytics"/>
        <category label="Anomaly Detection" term="Anomaly Detection"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[CausalTAD: LLM 정형 데이터 이상 탐지를 위한 인과적 열 순서 지정]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/06/25/causaltad-causal-knowledge-llm-tabular-anomaly-detection</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/06/25/causaltad-causal-knowledge-llm-tabular-anomaly-detection"/>
        <updated>2026-06-25T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[CausalTAD는 직렬화 전에 인과적 의존성을 고려하여 테이블 열 순서를 재정렬함으로써 LLM 기반 정형 데이터 이상 탐지 성능을 개선합니다. 혼합 유형 벤치마크에서 AnoLLM 대비 평균 AUC-ROC를 0.803에서 0.834로 높였으며, 이는 정형화된 장부 데이터의 이상 탐지에 직접적인 시사점을 제공합니다.]]></summary>
        <content type="html"><![CDATA[<p>이전 로그에서는 음의 로그 가능도(negative log-likelihood)를 통해 정형 데이터의 이상치를 점수화하도록 소형 LLM을 미세 조정하는 AnoLLM에 대해 다루었습니다. CausalTAD(arXiv:2602.07798)는 이에 대한 날카로운 후속 질문을 던집니다. LLM에 입력되는 열의 순서가 중요할까요? 결론부터 말하자면 '그렇다'입니다. 순서 지정에 인과적 구조를 주입하면 일관되고 재현 가능한 성능 향상을 얻을 수 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-소개">논문 소개<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/25/causaltad-causal-knowledge-llm-tabular-anomaly-detection#%EB%85%BC%EB%AC%B8-%EC%86%8C%EA%B0%9C" class="hash-link" aria-label="논문 소개에 대한 직접 링크" title="논문 소개에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=CausalTAD%3A%20LLM%20%EC%A0%95%ED%98%95%20%EB%8D%B0%EC%9D%B4%ED%84%B0%20%EC%9D%B4%EC%83%81%20%ED%83%90%EC%A7%80%EB%A5%BC%20%EC%9C%84%ED%95%9C%20%EC%9D%B8%EA%B3%BC%EC%A0%81%20%EC%97%B4%20%EC%88%9C%EC%84%9C%20%EC%A7%80%EC%A0%95" alt="2026-06-25-causaltad-causal-knowledge-llm-tabular-anomaly-detection" class="img_ev3q"></p>
<p>Wang 등은 AnoLLM 스타일의 LLM 이상 탐지기 위에서 작동하며 한 가지 핵심적인 변화를 주는 방법론인 CausalTAD를 제안합니다. 정형 데이터의 행을 무작위나 임의의 열 순서로 직렬화하는 대신, 열 간의 인과적 의존성을 발견하고 LLM이 행을 읽기 전에 해당 의존성을 반영하여 열 순서를 재정렬합니다.</p>
<p>이 논문은 두 가지 핵심 부분으로 구성됩니다. 첫째는 인과 중심의 열 순서 지정 모듈입니다. 저자들은 COAT 요인 추출 프레임워크를 수정하여 사용합니다. LLM이 열 메타데이터와 샘플을 읽어 고수준의 의미론적 요인(semantic factors)을 추출합니다(예: 신용카드 거래에서 '보상'이라는 요인은 금액과 가맹점 열을 포괄할 수 있습니다). 이러한 요인들로부터 PC, LiNGAM, FCI라는 세 가지 인과 발견 알고리즘이 각각 요인에 대한 유향 인과 그래프를 구축합니다. 그러면 열 재정렬 문제는 선형 순서 지정 문제(Linear Ordering Problem)가 됩니다. 즉, 직렬화된 텍스트에서 원인 열이 결과 열보다 먼저 나타나도록 유향 에지의 가중치 합을 최대화하는 순열 π를 찾는 것입니다. LP(선형 계획법)에는 최적에 가까운 해가 많기 때문에, 최적값의 90% 이내에 있는 약 K ≈ 10개의 순서를 샘플링하여 평균을 냅니다.</p>
<p>둘째는 인과 인식 가중치 재설정 모듈입니다. 모든 열이 동일하게 중요한 것은 아닙니다. 많은 요인에 영향을 미치는 열은 더 높은 가중치 αj = |M⁻¹(cj)|(해당 열이 기여하는 요인의 수)를 갖게 됩니다. 최종 이상치 점수는 K개의 순서에 걸친 열별 음의 로그 가능도의 가중 평균으로 산출됩니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/25/causaltad-causal-knowledge-llm-tabular-anomaly-detection#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">열 순서는 자기 회귀(autoregressive) LLM에게 중요한 귀납적 편향(inductive bias)입니다. 결과 열보다 원인 열을 먼저 배치하면 모델이 결과의 가능도를 할당할 때 올바른 문맥을 조건화할 수 있습니다.</li>
<li class="">원래의 열 수준이 아닌 요인 수준에서 인과 관계를 발견함으로써, 서로 다른 유형의 열 사이에서 직접적인 인과 발견이 어려워 노이즈가 발생하는 혼합 유형 테이블을 효과적으로 처리할 수 있습니다.</li>
<li class="">6개의 혼합 유형 벤치마크 데이터셋에서 SmolLM-135M을 사용한 CausalTAD는 평균 AUC-ROC 0.834를 기록하며 AnoLLM의 0.803 대비 3.1포인트의 절대적 성능 향상을 보였습니다(동일한 백본 모델 사용).</li>
<li class="">특히 Fake Job Posts 데이터셋에서 CausalTAD는 0.873점을 기록하여 AnoLLM의 0.800 대비 9.1%의 상대적 이득을 얻었습니다. 이는 실제 분류 시스템에서 유의미한 차이입니다.</li>
<li class="">30개의 수치형 ODDS 벤치마크 데이터셋 전체에서 CausalTAD는 가장 높은 평균 AUC-ROC를 달성하며 고전적 베이스라인(Isolation Forest, ECOD, KNN) 및 딥러닝 방법론(DeepSVDD, SLAD)을 일관되게 압도했습니다.</li>
<li class="">어블레이션 연구(ablation study)에서 세 가지 인과 발견 알고리즘 모두 무작위 순서보다 우수한 성능을 보였으며, 혼합 데이터셋에서는 LiNGAM이 PC와 FCI를 약간 앞섰습니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="장단점-분석">장단점 분석<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/25/causaltad-causal-knowledge-llm-tabular-anomaly-detection#%EC%9E%A5%EB%8B%A8%EC%A0%90-%EB%B6%84%EC%84%9D" class="hash-link" aria-label="장단점 분석에 대한 직접 링크" title="장단점 분석에 대한 직접 링크" translate="no">​</a></h2>
<p>인과적 열 순서가 도움이 된다는 핵심 주장은 충분히 뒷받침됩니다. 어블레이션 결과는 명확합니다. 무작위 순서를 세 가지 인과 발견 방법 중 하나로 교체하면 Fake Job Posts 벤치마크 결과가 개선되었으며(0.832에서 0.870–0.873으로), 요인 수 기반 가중치 재설정은 모든 구성에서 추가적인 도움이 되었습니다. 이는 신뢰할 만한 결과입니다.</p>
<p>덜 설득력 있게 느껴지는 부분은 부트스트래핑(bootstrapping) 가정입니다. 인과 그래프는 시스템이 분석하려는 바로 그 데이터에서 LLM을 사용해 의미론적 요인을 추출함으로써 구성됩니다. 만약 LLM이 도메인을 오해한다면(예: 비표준 열 이름을 사용하는 맞춤형 회계 시스템의 경우), 요인 추출이 틀릴 것이고, 잘못된 인과 그래프는 체계적인 편향을 유발하므로 무작위 순서보다 더 나쁠 수 있습니다. 저자들도 이러한 위험('요인 추출을 위한 LLM의 능력에 의존함')을 인정하고 있지만, 요인 추출 정확도를 독립적으로 벤치마킹하지는 않았습니다.</p>
<p>또한 논문에서 제시하는 것보다 더 심각한 계산 오버헤드 문제가 있습니다. 세 가지 인과 발견 알고리즘을 실행하고, LP를 풀고, K개의 순서를 샘플링한 다음, 모든 테스트 포인트의 K개 직렬화 버전에 대해 추론을 실행하면 추론 비용이 K배로 증가합니다. 수백만 개의 항목이 있는 장부의 경우 이는 매우 중요한 문제입니다. 논문은 "향후 연구에서 효율성 개선에 집중할 수 있다"고 언급하지만 구체적인 프로파일링은 제공하지 않습니다.</p>
<p>마지막으로, 30개의 수치형 ODDS 데이터셋은 이미 연구가 많이 되어 이러한 방법론들에 대해 포화 상태라고 볼 수 있습니다. 더 의미 있는 신호는 금융 분야에서 현실적인 6개의 혼합 유형 데이터셋에 있으며, 여기서의 개선 사항은 실질적이긴 하지만 절대적인 수치 면에서는 다소 완만합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai에서-중요한-이유">금융 AI에서 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/25/causaltad-causal-knowledge-llm-tabular-anomaly-detection#%EA%B8%88%EC%9C%B5-ai%EC%97%90%EC%84%9C-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에서 중요한 이유에 대한 직접 링크" title="금융 AI에서 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>Beancount 거래는 진정한 인과 구조를 가지고 있습니다. 기입 금액(amount)은 계정(account) 선택을 인과적으로 유도하고, 계정은 상대방(counterparty)에 대한 기대를 유도하며, 적요(memo) 텍스트는 이 세 가지 모두의 인과적 하류에 있습니다. 무작위 열 직렬화는 이를 무시하므로, AnoLLM 스타일의 모델은 "memo: groceries | account: Expenses<!-- -->:Food<!-- --> | amount: $4200"를 올바른 순서의 버전과 다름없이 처리하게 됩니다.</p>
<p>CausalTAD는 "금액과 계정이 먼저 온다"는 사실을 규칙으로 하드코딩하지 않고도 인코딩할 수 있는 원칙적인 방법을 제공합니다. Bean Labs 감사 에이전트의 경우, 이는 실용적인 아키처 선택을 시사합니다. 한 배치의 거래에 대해 이상 탐지 점수를 매기기 전, 장부의 열 스키마에 대한 인과 그래프를 찾는 과정을 한 번 거친 후 이후의 모든 추론에 해당 고정 순서를 사용하는 것입니다. 이렇게 하면 오버헤드는 거래별이 아닌 스키마 수준에서 한 번만 발생합니다.</p>
<p>논문의 신용카드 부정 탐지 예시는 장부 이상 탐지와 본질적으로 동일한 작업 구조를 가집니다. 이질적인 특징들, 희귀한 레이블, 그리고 도메인 전문가들은 직관적으로 알지만 LLM은 무시할 수 있는 인과적 순서 등이 그렇습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어볼-거리">더 읽어볼 거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/25/causaltad-causal-knowledge-llm-tabular-anomaly-detection#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%BC-%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="더 읽어볼 거리에 대한 직접 링크" title="더 읽어볼 거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>AD-LLM: Benchmarking Large Language Models for Anomaly Detection</strong> (arXiv:2412.11142, ACL Findings 2025) — CausalTAD가 속한 세 가지 LLM 이상 탐지 패러다임에 대한 체계적인 벤치마크입니다. 단일한 AnoLLM vs CausalTAD 비교보다는 전체적인 지형을 파악할 수 있게 해줍니다.</li>
<li class=""><strong>COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data</strong> (Liu et al., 2024) — CausalTAD가 차용한 요인 추출 프레임워크입니다. 이 작동 방식을 이해하면 인과 그래프 품질이 저하될 수 있는 지점을 명확히 알 수 있습니다.</li>
<li class=""><strong>Causal discovery in heterogeneous data: a survey</strong> — 혼합 유형 정형 데이터에서 PC vs LiNGAM vs FCI의 상대적 장점을 이해하는 데 도움이 됩니다. 논문에서는 세 가지를 상호 교체 가능한 것으로 취급하지만, 각각 서로 다른 독립성 가정을 가집니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="LLM" term="LLM"/>
        <category label="AI" term="AI"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Fraud Detection" term="Fraud Detection"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Anomaly Detection" term="Anomaly Detection"/>
        <category label="Beancount" term="Beancount"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[AnoLLM: 금융 데이터의 정형 변칙 탐지를 위한 LLM 미세 조정]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/06/24/anollm-llm-fine-tuning-tabular-anomaly-detection</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/06/24/anollm-llm-fine-tuning-tabular-anomaly-detection"/>
        <updated>2026-06-24T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[AnoLLM(ICLR 2025)은 정형 변칙 탐지를 LLM 밀도 추정으로 재구성합니다. 즉, 정상 행에 대해 미세 조정을 수행하고 음의 로그 가능도로 점수를 산출합니다. 이 방식은 혼합형 사기 데이터셋에서 고전적인 방법들을 능가하지만, 순수 수치형 데이터에서는 이점이 없으며 Beancount 장부 항목의 변칙을 탐지하는 데 실질적인 시사점을 제공합니다.]]></summary>
        <content type="html"><![CDATA[<p>2일 전에 읽은 제로샷 LLM 변칙 탐지 논문(arXiv:2406.16308)은 GPT-4가 별도의 훈련 없이도 ODDS 벤치마크에서 ECOD와 같은 고전적인 기준선(baselines)에 필적하는 정형 이상치를 식별할 수 있음을 보여주었습니다. 하지만 명백한 약점이 있었습니다. 모델에게 변칙적인 행 인덱스 목록을 출력하도록 요청하는 방식은 매우 취약하다는 점입니다. 오픈 소스 모델은 일상적으로 인덱스에 대해 환각(hallucination)을 일으키거나, 범위를 벗어나거나, 혹은 모든 행을 의심스러운 것으로 표시하곤 합니다. 아마존의 Che-Ping Tsai, Ganyu Teng, Phillip Wallis, Wei Ding이 ICLR 2025에 발표한 AnoLLM은 이러한 취약성을 해결하는 동시에, 순수 수치형 기준선이 고전하는 혼합형 데이터셋 영역으로 영역을 확장했습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-내용">논문 내용<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/24/anollm-llm-fine-tuning-tabular-anomaly-detection#%EB%85%BC%EB%AC%B8-%EB%82%B4%EC%9A%A9" class="hash-link" aria-label="논문 내용에 대한 직접 링크" title="논문 내용에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=AnoLLM%3A%20%EA%B8%88%EC%9C%B5%20%EB%8D%B0%EC%9D%B4%ED%84%B0%EC%9D%98%20%EC%A0%95%ED%98%95%20%EB%B3%80%EC%B9%99%20%ED%83%90%EC%A7%80%EB%A5%BC%20%EC%9C%84%ED%95%9C%20LLM%20%EB%AF%B8%EC%84%B8%20%EC%A1%B0%EC%A0%95" alt="2026-06-24-anollm-llm-fine-tuning-tabular-anomaly-detection" class="img_ev3q"></p>
<p>AnoLLM은 정형 변칙 탐지를 프롬프트 기반 분류가 아닌 언어 모델 밀도 추정으로 재정의합니다. LLM에게 어떤 행이 의심스러운지 묻는 대신, 저자들은 사전 훈련된 언어 모델을 직렬화된 분포 내(정상) 훈련 행 데이터로 미세 조정(fine-tuning)한 다음, 학습된 분포 하에서의 음의 로그 가능도(Negative Log-Likelihood, NLL)를 통해 각 테스트 행의 점수를 매깁니다. 훈련 분포와 전혀 닮지 않은 행은 높은 NLL을 갖게 되며, 이것이 곧 변칙 점수가 됩니다. 인덱스 형식도, 출력 파싱도, 취약한 정규식 추출도 필요 없습니다.</p>
<p>직렬화 과정은 각 테이블 행을 특성(feature) 이름과 값이 포함된 자연어 문자열로 변환합니다. 텍스트 값 컬럼의 경우, 긴 설명이 기계적으로 더 높은 확률 비용을 축적하는 길이 편향을 피하기 위해 컬럼별로 NLL을 정규화합니다. 수치형 및 범주형 컬럼의 경우, 가공되지 않은 토큰 수준의 NLL을 필드 전체에 걸쳐 합산합니다. 모델은 준지도 학습(semi-supervised) 설정에서 미세 조정됩니다. 즉, 정상으로 레이블이 지정된 행만 훈련에 사용되며, 분산 GPU 훈련을 통해 최대 2,000단계까지 수행됩니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/24/anollm-llm-fine-tuning-tabular-anomaly-detection#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class=""><strong>출력 형식 문제:</strong> 이전의 인덱스 예측 접근 방식은 LLM이 배치에서 변칙적인 행 인덱스를 안정적으로 출력해야 했습니다. Llama 계열 모델은 종종 잘못된 인덱스와 값을 짝지거나, 배치 크기를 벗어난 인덱스를 생성하거나, 단순히 모든 것을 변칙으로 나열하곤 합니다. NLL은 이 문제를 완전히 우회합니다.</li>
<li class="">AnoLLM은 Kaggle의 자동차 보험 사기 탐지 및 전자상거래 사기 데이터셋을 포함하여, 혼합 특성 유형을 가진 6개의 벤치마크 데이터셋에서 최고의 성능을 달성했습니다.</li>
<li class="">수치 데이터가 주를 이루는 30개의 ODDS 벤치마크 데이터셋에서 AnoLLM은 최상위 고전 기준선들과 대등한 성능을 보였습니다. 확연히 더 낫다기보다는 경쟁력이 있는 수준입니다.</li>
<li class="">텍스트 특성에 대한 컬럼별 NLL 정규화는 작지만 핵심적인 엔지니어링 결정입니다. 이 과정이 없다면 30개 토큰으로 된 거래 설명이 두 자리 숫자의 금액보다 점수를 압도하게 되는데, 이는 잘못된 귀납적 편향(inductive bias)입니다.</li>
<li class=""><strong>훈련 기준선 문맥:</strong> 제로샷 GPT-4 방식(arXiv:2406.16308)은 ODDS에서 평균 AUROC 74.1을 달성하며, 이는 ECOD(75.5) 및 KNN(70.7)과 비슷합니다. AnoLLM의 장점은 특히 텍스트와 범주형 특성이 유의미한 변칙 신호를 담고 있는 데이터셋에서 두드러집니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="장점과-한계">장점과 한계<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/24/anollm-llm-fine-tuning-tabular-anomaly-detection#%EC%9E%A5%EC%A0%90%EA%B3%BC-%ED%95%9C%EA%B3%84" class="hash-link" aria-label="장점과 한계에 대한 직접 링크" title="장점과 한계에 대한 직접 링크" translate="no">​</a></h2>
<p>핵심적인 NLL 아이디어는 타당합니다. 미세 조정된 언어 모델을 직렬화된 행에 대한 밀도 추정기로 사용하는 것은 원칙적이며, 고전적인 비지도 탐지기가 컬럼별로 적용될 때 깔끔하게 처리하지 못하는 모든 컬럼의 결합 분포(joint distribution)를 자연스럽게 동시에 처리합니다. 인덱스 예측 문제에 대한 해결책은 진정으로 유용하며 제로샷 기준선과의 비교도 공정합니다.</p>
<p>아쉬운 점은 논문에서 충분히 다루지 않은 비용 대비 편익의 격차입니다. AnoLLM은 추론을 위해 LLM을 미세 조정하고 서빙해야 하는데, 이는 CPU에서 수초 만에 ECOD나 IsolationForest를 실행하는 것에 비해 상당한 인프라 투자를 필요로 합니다. ODDS 벤치마크(순수 수치형)에서 AnoLLM은 더 나은 것이 아니라 단지 "대등한" 수준입니다. 따라서 AnoLLM의 가치는 전적으로 혼합형 데이터 영역에 있는데, 평가된 6개의 데이터셋은 모두 Kaggle의 사기 탐지 데이터입니다. 6개의 데이터셋은 강력한 추천을 뒷받침하기에는 빈약한 경험적 기반이며, 특히 Kaggle의 데이터셋은 깨끗한 스키마, 고정된 컬럼 의미론, 알려진 정답(ground truth)을 갖는 경향이 있습니다. 이는 실제 운영 환경의 장부 데이터가 종종 결여하고 있는 요소들입니다.</p>
<p>컬럼 순서 문제 또한 미결 과제로 남아 있습니다. CausalTAD(arXiv:2602.07798)는 즉시 이 간극을 식별했습니다. AnoLLM은 필드 간의 인과 관계를 무시하고 임의의 순서로 컬럼을 직렬화합니다. 계정 유형이 유효한 거래 범위를 결정하고, 이것이 예상 거래 상대방에 영향을 미치는 것과 같이 인과 관계가 명확한 구조화된 데이터에서 이는 실질적인 한계입니다. CausalTAD는 순서 재배치를 선형 순서화 문제로 프레이밍하고 30개 이상의 데이터셋에서 AnoLLM보다 일관된 개선을 보고했습니다. 이러한 간극이 존재하고 빠르게 발견되었다는 것은 AnoLLM의 직렬화 설계가 완전히 숙고되지 않았음을 시사합니다.</p>
<p>논문에서 다루지 않은 규모의 문제도 있습니다. 어느 정도 규모의 정상 훈련 예시가 있어야 수치 특성에 직접 훈련된 정형 딥러닝 모델보다 LLM 미세 조정이 더 가치 있게 될까요? 수천 개의 항목이 있는 개인 Beancount 장부의 경우, 컴퓨팅 비용이 정확도 이득을 쉽게 압도할 수 있습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금�융-ai에서-이것이-중요한-이유">금융 AI에서 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/24/anollm-llm-fine-tuning-tabular-anomaly-detection#%EA%B8%88%EC%9C%B5-ai%EC%97%90%EC%84%9C-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" title="금융 AI에서 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>Beancount 장부 항목은 금액(수치형), 계정 이름(구조화된 텍스트), 수취인/설명(자유 텍스트), 태그(범주형), 날짜(구조화된 데이터) 등 AnoLLM이 목표로 하는 혼합형 데이터의 전형적인 예입니다. <code>2024-03-15 * "AWS" "Cloud invoice" Assets:Checking -$2,400</code>과 같은 단일 행은 이 모든 유형의 정보를 동시에 인코딩합니다. 고전적인 변칙 탐지기는 각 컬럼 유형을 별도로 처리해야 하고, "AWS" 인보이스는 특정 범위 내에 있어야 하며 특정 계정으로 처리되어야 한다는 결합된 패턴인 컬럼 간의 상관관계를 놓치기 때문에 이 영역에서 어려움을 겪습니다.</p>
<p>AnoLLM의 NLL 접근 방식은 원칙적으로 과거의 정상 항목으로부터 이러한 결합 패턴을 학습하고 모든 컬럼 조합에 걸쳐 편차를 찾아낼 수 있습니다. 이는 규칙 기반의 JET(장부 항목 테스트)나 단일 컬럼 통계 테스트보다 잠재적으로 더 유용합니다.</p>
<p>그렇기는 하지만, 복식 부기 제약 조건은 AnoLLM이 직렬화된 행만으로는 학습할 수 없는 구조적 지식입니다. 차변과 대변의 합은 같아야 하며, 계정 계층 구조는 준수되어야 합니다. 이러한 도메인 불변성(domain invariants)은 통계적 규칙성이 아닌 엄격한 제약 조건이며, 훈련 데이터에 예외나 반올림 오차(rounding artifacts)가 포함되어 있다면 아무리 많은 LLM 미세 조정을 거치더라도 이를 안정적으로 강제할 수 없습니다. 올바른 아키텍처는 아마도 의미론적 변칙을 위한 AnoLLM의 NLL 점수 산출과 구조적 변칙을 위한 명시적 규칙 검사를 결합하는 형태가 될 것입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="더-읽어볼-거리">더 읽어볼 거리<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/24/anollm-llm-fine-tuning-tabular-anomaly-detection#%EB%8D%94-%EC%9D%BD%EC%96%B4%EB%B3%BC-%EA%B1%B0%EB%A6%AC" class="hash-link" aria-label="더 읽어볼 거리에 대한 직접 링크" title="더 읽어볼 거리에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">CausalTAD (arXiv:2602.07798) — 인과적 컬럼 순서를 주입하여 AnoLLM을 직접적으로 개선한 연구로, 가장 즉각적인 후속 검토 대상입니다.</li>
<li class="">AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — 개별 방법론 논문에서 누락된 체계적인 다중 패러다임 평가를 제공합니다.</li>
<li class="">"Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) — AnoLLM이 기준선으로 사용하는 BE-GREAT 모델입니다. 이를 이해하면 AnoLLM이 인덱스 예측 이상으로 개선한 점이 무엇인지 명확해집니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="AI" term="AI"/>
        <category label="LLM" term="LLM"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Fraud Detection" term="Fraud Detection"/>
        <category label="Data Science" term="Data Science"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Finance" term="Finance"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Beancount DSL 생성에서 LLM 점수 2.3%: LLMFinLiteracy 벤치마크]]></title>
        <id>https://beancount.io/ko/bean-labs/research-logs/2026/06/23/llm-beancount-dsl-financial-literacy-benchmark</id>
        <link href="https://beancount.io/ko/bean-labs/research-logs/2026/06/23/llm-beancount-dsl-financial-literacy-benchmark"/>
        <updated>2026-06-23T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[LLMFinLiteracy 벤치마크에 따르면 5개의 약 7B 규모 공개 가중치 모델이 완전히 정확한 Beancount 트랜잭션을 생성할 확률은 2.3%에 불과했습니다. 실패 원인은 구문이 아닌 회계적 추론에 집중되어 있으며, 이는 신뢰할 수 있는 라이트백(write-back) 에이전트를 위해 루프 내 컴파일러(compiler-in-the-loop) 피드백이 핵심적인 요소임을 시사합니다.]]></summary>
        <content type="html"><![CDATA[<p>LOG-001 이후 제가 기다려온 논문입니다. 바로 LLM이 자연어 금융 시나리오로부터 유효한 Beancount DSL 트랜잭션을 생성할 수 있는지에 대한 직접적인 실증 테스트입니다. 베를린 응용과학 대학교의 Figueroa 등은 텍스트 기반 회계 분야에서 LLM의 금융 트랜잭션 생성 능력에 대해 발표된 최초의 평가(제가 아는 한 그들의 주장이 맞습니다)를 제시했습니다. 짧은 결론은 다음과 같습니다. 연쇄 사고(chain-of-thought) 프롬프팅을 사용하고 실제 Beancount 대차대조표를 문맥으로 제공하더라도, LLM은 안정적으로 이를 수행하지 못합니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="논문-소개">논문 소개<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/23/llm-beancount-dsl-financial-literacy-benchmark#%EB%85%BC%EB%AC%B8-%EC%86%8C%EA%B0%9C" class="hash-link" aria-label="논문 소개에 대한 직접 링크" title="논문 소개에 대한 직접 링크" translate="no">​</a></h2>
<p><img decoding="async" loading="lazy" src="https://opengraph-image.blockeden.xyz/api/og-beancount-io?title=Beancount%20DSL%20%EC%83%9D%EC%84%B1%EC%97%90%EC%84%9C%20LLM%20%EC%A0%90%EC%88%98%202.3%25%3A%20LLMFinLiteracy%20%EB%B2%A4%EC%B9%98%EB%A7%88%ED%81%AC" alt="2026-06-23-llm-beancount-dsl-financial-literacy-benchmark" class="img_ev3q"></p>
<p>Figueroa, Grundmann, Freidank, Löser, Nejdl은 LLMFinLiteracy라고 부르는 두 가지 작업의 벤치마크에서 5개의 약 7B 규모 공개 가중치 모델을 평가했습니다. 작업 1은 5개의 DAX 상장 기업(Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP) 중 하나의 실제 분기별 대차대조표가 주어졌을 때, 특정 유동성 비율(유동비율, 당좌비율, 또는 현금비율)에 영향을 미치는 텍스트 시나리오를 생성하도록 모델에 요구합니다. 작업 2는 모델이 이러한 시나리오를 컴파일 가능한 Beancount 트랜잭션으로 번역하도록 요구합니다. Beancount 컴파일러는 기본 구문 검사기 역할을 하며, 인간 도메인 전문가는 의미적 정확성을 평가합니다. 이 논문은 두 작업에 걸쳐 12개의 오류 분류 체계를 도입하고, 복식 부기 규칙, 입출력 예시, Beancount 형식의 실제 기업 대차대조표를 포함하는 9단계 연쇄 사고 프롬프트를 사용합니다. 평가된 모델인 Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B, CodeQwen-1.5-7B는 금융 데이터의 민감성 때문에 모두 온프레미스에서 실행되었습니다. 말뭉치는 총 1,500개의 생성된 샘플로 구성되며, 그중 인간 전문가가 평가한 300개의 층화된 항목이 포함됩니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="핵심-아이디어">핵심 아이디어<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/23/llm-beancount-dsl-financial-literacy-benchmark#%ED%95%B5%EC%8B%AC-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4" class="hash-link" aria-label="핵심 아이디어에 대한 직접 링크" title="핵심 아이디어에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">평가된 300개의 시나리오-트랜잭션 쌍 중 단 7개(2.3%)만이 엔드투엔드로 완전히 정확했습니다. 범용 모델 3개로만 제한하더라도 정확도는 3.8%로 상승하는 데 그칩니다.</li>
<li class="">가장 우수한 두 모델인 Qwen-2-7B와 Mistral-7B는 시나리오 정확도가 각각 21.67%와 20.00%였으며, 컴파일 가능한 트랜잭션 생성 정확도는 각각 16.67%와 10.00%에 불과했습니다.</li>
<li class="">코드 특화 모델(CodeLlama, CodeQwen)은 두 작업 모두에서 0점을 기록했습니다. 이들은 프롬프트 템플릿에 대해 "Processed — Waiting for next input"이라는 문자열로 응답하며 작업을 완전히 무시했습니다.</li>
<li class="">구문(Syntax)이 병목 현상은 아닙니다. 단 한 개의 모델도 구문 오류를 생성하지 않았습니다. 실패의 원인은 전적으로 회계적 <strong>추론</strong>에 있었습니다. Qwen-2(61.67%)와 Llama-3(38.33%)에서는 잔액 오류가 지배적이었고, Mistral은 주로 제공된 대차대조표에 존재하지 않는 계정을 참조했습니다(45% 알 수 없는 계정 오류).</li>
<li class="">성공적으로 컴파일된 트랜잭션 중 상당수가 의미적으로 틀렸습니다. 모델이 가장 즐겨 사용하는 속임수는 부채 감소를 "부채 매각"이라고 부르는 것이었는데, 이는 현금은 증가시키지만 잘못된 이유로 처리된 것입니다.</li>
<li class="">자동 평가자로 사용된 GPT-4o는 제시된 10개의 터무니없는 시나리오 모두에서 불일치를 찾아내는 데 실패했습니다. 이는 LLM 자기 평가가 회계 출력의 신뢰할 수 있는 품질 관문이 아님을 확인해 줍니다.</li>
<li class="">모델은 일반화하기보다는 프롬프트의 입출력 예시를 대량으로 복사하는 경향을 보였습니다. 7개의 정확한 쌍은 제공된 예시 트랜잭션 구조와 매우 유사했습니다.</li>
</ul>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="유효한-점과-그렇지-않은-점">유효한 점과 그렇지 않은 점<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/23/llm-beancount-dsl-financial-literacy-benchmark#%EC%9C%A0%ED%9A%A8%ED%95%9C-%EC%A0%90%EA%B3%BC-%EA%B7%B8%EB%A0%87%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%A0%90" class="hash-link" aria-label="유효한 점과 그렇지 않은 점에 대한 직접 링크" title="유효한 점과 그렇지 않은 점에 대한 직접 링크" translate="no">​</a></h2>
<p>이 논문의 핵심적인 실증적 기여는 탄탄합니다. Beancount 컴파일러는 객관적이고 재현 가능한 정확성 기준이며, 장난감 데이터가 아닌 실제 기업 대차대조표를 사용한 것은 생태학적 타당성을 더합니다. 계층적 오류 분류 체계는 사려 깊게 설계되었습니다. 첫 번째 오류에서 평가를 중단함으로써 무의미한 출력에 대해 "부분 점수"가 부풀려지는 것을 방지했습니다.</p>
<p>그렇긴 하지만, 저자들도 대부분 인정하는 명백한 한계가 있습니다. 2023~2024년의 5개 약 7B 공개 가중치 모델은 능력 지형의 좁은 부분만을 보여줍니다. 개인정보 보호 이유로 GPT-4o와 Claude가 제외되었는데, 이는 이해할 만하지만 헤드라인 수치(2.3% 정확도)가 기술적 최전선을 과소평가하고 있음을 의미합니다. 내재된 도메인 지식을 테스트하기 위해 프롬프트에서 재무 비율 공식이 의도적으로 제외되었습니다. 이는 방법론적으로 흥미로운 선택이지만, 공식 문서가 포함될 실제 시스템의 결과와는 비교하기 어렵게 만듭니다. 또한 5개 모델, 3개 비율, 5개 기업에 걸쳐 인간이 평가한 300개의 샘플은 규모가 작습니다. 모델당 비율당 데이터(12개 샘플)는 분산에 대해 강력한 결론을 내리기에는 너무 적습니다.</p>
<p>가장 흥미로운 방법론적 공백은 반복적 또는 피드백 기반 프로토콜이 없다는 점입니다. 도구 호출도, 자기 수정도, 컴파일러 피드백 루프도 없이 일회성 생성(one-shot generation)만 수행되었습니다. CRITIC(LOG-012) 및 관련 연구에서 도구 상호작용형 정제가 검증 가능한 출력을 가진 작업의 정확도를 실질적으로 향상시킨다는 점을 고려할 때, 'Beancount 컴파일러를 루프에 포함시킨' 실험이었다면 배포 가능성에 대해 훨씬 더 유익한 정보를 제공했을 것입니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="금융-ai-분야에서-이것이-중요한-이유">금융 AI 분야에서 이것이 중요한 이유<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/23/llm-beancount-dsl-financial-literacy-benchmark#%EA%B8%88%EC%9C%B5-ai-%EB%B6%84%EC%95%BC%EC%97%90%EC%84%9C-%EC%9D%B4%EA%B2%83%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0" class="hash-link" aria-label="금융 AI 분야에서 이것이 중요한 이유에 대한 직접 링크" title="금융 AI 분야에서 이것이 중요한 이유에 대한 직접 링크" translate="no">​</a></h2>
<p>Bean Labs 라이트백 에이전트의 모든 설계 결정은 LLM이 Beancount DSL로 무엇을 할 수 있는지에 대한 가정에 기반합니다. 이 논문은 그 첫 번째 실증적 닻입니다. 헤드라인 결과는 냉혹하지만 유용한 방식으로 해석될 수 있습니다.</p>
<p>첫째, 실패 모드는 무작위가 아니라 구체적입니다. 잔액 오류와 알 수 없는 계정이 두 가지 주요 문제이며, 두 가지 모두 컴파일러 피드백 루프로 해결 가능합니다. Beancount 컴파일러는 어떤 계정이 알 수 없는지, 트랜잭션 잔액이 맞는지 정확히 알려줍니다. 단 한 번 생성하고 멈추는 것이 아니라 컴파일러 출력에 따라 반복하는 에이전트 아키텍처는 여기의 일회성 결과보다 훨씬 뛰어난 성능을 보일 것입니다. 둘째, 구문은 이미 해결된 문제입니다. 모델은 Beancount의 표면 문법을 명확하게 학습했습니다. 단지 금융적 의도를 올바른 계정 이동으로 안정적으로 번역하지 못할 뿐입니다. 이 차이는 프롬프팅과 미세 조정의 어디에 투자해야 할지를 결정하는 데 중요합니다. 셋째, GPT-4o가 회계 품질을 자동으로 평가할 수 없다는 결과는 자동화된 검증 시스템의 기준을 높입니다. LLM 비평가가 아니라 컴파일러와 도메인 전문가의 현장 점검이 필요합니다.</p>
<p>또한 이 논문은 제가 이상 탐지 작업(LOG-049)에서 의심했던 점을 확인해 주었습니다. 금융 트랜잭션을 처리하는 LLM은 너무 쉽게 컴파일하고 제출해 버립니다. "오류 | 컴파일 성공" 카테고리(구문 검사는 통과하지만 의미적으로 틀린 트랜잭션)는 라이트백 안전 가드레일이 반드시 포착해야 하는 실패 모드입니다. 트랜잭션 잔액이 완벽하게 맞아도 수익을 부채 감소로 기록할 수 있으며, 이는 순수하게 구문론적인 검사로는 감지되지 않습니다.</p>
<h2 class="anchor anchorTargetStickyNavbar_Vzrq" id="다음에-읽어볼-내용">다음에 읽어볼 내용<a href="https://beancount.io/ko/bean-labs/research-logs/2026/06/23/llm-beancount-dsl-financial-literacy-benchmark#%EB%8B%A4%EC%9D%8C%EC%97%90-%EC%9D%BD%EC%96%B4%EB%B3%BC-%EB%82%B4%EC%9A%A9" class="hash-link" aria-label="다음에 읽어볼 내용에 대한 직접 링크" title="다음에 읽어볼 내용에 대한 직접 링크" translate="no">​</a></h2>
<ul>
<li class="">AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — 배치 탐지 방식의 대안으로 우도 기반 이상 점수 산출 방식을 제안합니다. Beancount 컴파일러 신호와 결합하여 구조적으로는 유효하지만 통계적으로 이상한 항목을 찾아내는 데 자연스럽게 연결됩니다.</li>
<li class="">ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — 신뢰도가 낮은 결정을 더 큰 모델이나 인간에게 라우팅합니다. Beancount 라이트백 에이전트가 컴파일러 피드백 루프 후에도 언제 인간의 검토를 요청해야 하는지에 대한 문제에 직접적으로 답변합니다.</li>
<li class="">CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — 이 논문에서 평가한 아키텍처 위에 루프 내 컴파일러 수정 에이전트를 구축하는 데 가장 관련이 깊은 기존 연구입니다.</li>
</ul>]]></content>
        <author>
            <name>Mike Thrift</name>
        </author>
        <category label="LLM" term="LLM"/>
        <category label="Beancount" term="Beancount"/>
        <category label="Plain-Text Accounting" term="Plain-Text Accounting"/>
        <category label="AI" term="AI"/>
        <category label="Machine Learning" term="Machine Learning"/>
        <category label="Financial Literacy" term="Financial Literacy"/>
        <category label="Double-Entry" term="Double-Entry"/>
        <category label="Transaction Validation" term="Transaction Validation"/>
    </entry>
</feed>