Beancount DSL 생성에서 LLM 점수 2.3%: LLMFinLiteracy 벤치마크

LOG-001 이후 제가 기다려온 논문입니다. 바로 LLM이 자연어 금융 시나리오로부터 유효한 Beancount DSL 트랜잭션을 생성할 수 있는지에 대한 직접적인 실증 테스트입니다. 베를린 응용과학 대학교의 Figueroa 등은 텍스트 기반 회계 분야에서 LLM의 금융 트랜잭션 생성 능력에 대해 발표된 최초의 평가(제가 아는 한 그들의 주장이 맞습니다)를 제시했습니다. 짧은 결론은 다음과 같습니다. 연쇄 사고(chain-of-thought) 프롬프팅을 사용하고 실제 Beancount 대차대조표를 문맥으로 제공하더라도, LLM은 안정적으로 이를 수행하지 못합니다.

논문 소개

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개의 층화된 항목이 포함됩니다.

핵심 아이디어

• 평가된 300개의 시나리오-트랜잭션 쌍 중 단 7개(2.3%)만이 엔드투엔드로 완전히 정확했습니다. 범용 모델 3개로만 제한하더라도 정확도는 3.8%로 상승하는 데 그칩니다.
• 가장 우수한 두 모델인 Qwen-2-7B와 Mistral-7B는 시나리오 정확도가 각각 21.67%와 20.00%였으며, 컴파일 가능한 트랜잭션 생성 정확도는 각각 16.67%와 10.00%에 불과했습니다.
• 코드 특화 모델(CodeLlama, CodeQwen)은 두 작업 모두에서 0점을 기록했습니다. 이들은 프롬프트 템플릿에 대해 "Processed — Waiting for next input"이라는 문자열로 응답하며 작업을 완전히 무시했습니다.
• 구문(Syntax)이 병목 현상은 아닙니다. 단 한 개의 모델도 구문 오류를 생성하지 않았습니다. 실패의 원인은 전적으로 회계적 추론에 있었습니다. Qwen-2(61.67%)와 Llama-3(38.33%)에서는 잔액 오류가 지배적이었고, Mistral은 주로 제공된 대차대조표에 존재하지 않는 계정을 참조했습니다(45% 알 수 없는 계정 오류).
• 성공적으로 컴파일된 트랜잭션 중 상당수가 의미적으로 틀렸습니다. 모델이 가장 즐겨 사용하는 속임수는 부채 감소를 "부채 매각"이라고 부르는 것이었는데, 이는 현금은 증가시키지만 잘못된 이유로 처리된 것입니다.
• 자동 평가자로 사용된 GPT-4o는 제시된 10개의 터무니없는 시나리오 모두에서 불일치를 찾아내는 데 실패했습니다. 이는 LLM 자기 평가가 회계 출력의 신뢰할 수 있는 품질 관문이 아님을 확인해 줍니다.
• 모델은 일반화하기보다는 프롬프트의 입출력 예시를 대량으로 복사하는 경향을 보였습니다. 7개의 정확한 쌍은 제공된 예시 트랜잭션 구조와 매우 유사했습니다.

유효한 점과 그렇지 않은 점

이 논문의 핵심적인 실증적 기여는 탄탄합니다. Beancount 컴파일러는 객관적이고 재현 가능한 정확성 기준이며, 장난감 데이터가 아닌 실제 기업 대차대조표를 사용한 것은 생태학적 타당성을 더합니다. 계층적 오류 분류 체계는 사려 깊게 설계되었습니다. 첫 번째 오류에서 평가를 중단함으로써 무의미한 출력에 대해 "부분 점수"가 부풀려지는 것을 방지했습니다.

그렇긴 하지만, 저자들도 대부분 인정하는 명백한 한계가 있습니다. 2023~2024년의 5개 약 7B 공개 가중치 모델은 능력 지형의 좁은 부분만을 보여줍니다. 개인정보 보호 이유로 GPT-4o와 Claude가 제외되었는데, 이는 이해할 만하지만 헤드라인 수치(2.3% 정확도)가 기술적 최전선을 과소평가하고 있음을 의미합니다. 내재된 도메인 지식을 테스트하기 위해 프롬프트에서 재무 비율 공식이 의도적으로 제외되었습니다. 이는 방법론적으로 흥미로운 선택이지만, 공식 문서가 포함될 실제 시스템의 결과와는 비교하기 어렵게 만듭니다. 또한 5개 모델, 3개 비율, 5개 기업에 걸쳐 인간이 평가한 300개의 샘플은 규모가 작습니다. 모델당 비율당 데이터(12개 샘플)는 분산에 대해 강력한 결론을 내리기에는 너무 적습니다.

가장 흥미로운 방법론적 공백은 반복적 또는 피드백 기반 프로토콜이 없다는 점입니다. 도구 호출도, 자기 수정도, 컴파일러 피드백 루프도 없이 일회성 생성(one-shot generation)만 수행되었습니다. CRITIC(LOG-012) 및 관련 연구에서 도구 상호작용형 정제가 검증 가능한 출력을 가진 작업의 정확도를 실질적으로 향상시킨다는 점을 고려할 때, 'Beancount 컴파일러를 루프에 포함시킨' 실험이었다면 배포 가능성에 대해 훨씬 더 유익한 정보를 제공했을 것입니다.

금융 AI 분야에서 이것이 중요한 이유

Bean Labs 라이트백 에이전트의 모든 설계 결정은 LLM이 Beancount DSL로 무엇을 할 수 있는지에 대한 가정에 기반합니다. 이 논문은 그 첫 번째 실증적 닻입니다. 헤드라인 결과는 냉혹하지만 유용한 방식으로 해석될 수 있습니다.

첫째, 실패 모드는 무작위가 아니라 구체적입니다. 잔액 오류와 알 수 없는 계정이 두 가지 주요 문제이며, 두 가지 모두 컴파일러 피드백 루프로 해결 가능합니다. Beancount 컴파일러는 어떤 계정이 알 수 없는지, 트랜잭션 잔액이 맞는지 정확히 알려줍니다. 단 한 번 생성하고 멈추는 것이 아니라 컴파일러 출력에 따라 반복하는 에이전트 아키텍처는 여기의 일회성 결과보다 훨씬 뛰어난 성능을 보일 것입니다. 둘째, 구문은 이미 해결된 문제입니다. 모델은 Beancount의 표면 문법을 명확하게 학습했습니다. 단지 금융적 의도를 올바른 계정 이동으로 안정적으로 번역하지 못할 뿐입니다. 이 차이는 프롬프팅과 미세 조정의 어디에 투자해야 할지를 결정하는 데 중요합니다. 셋째, GPT-4o가 회계 품질을 자동으로 평가할 수 없다는 결과는 자동화된 검증 시스템의 기준을 높입니다. LLM 비평가가 아니라 컴파일러와 도메인 전문가의 현장 점검이 필요합니다.

또한 이 논문은 제가 이상 탐지 작업(LOG-049)에서 의심했던 점을 확인해 주었습니다. 금융 트랜잭션을 처리하는 LLM은 너무 쉽게 컴파일하고 제출해 버립니다. "오류 | 컴파일 성공" 카테고리(구문 검사는 통과하지만 의미적으로 틀린 트랜잭션)는 라이트백 안전 가드레일이 반드시 포착해야 하는 실패 모드입니다. 트랜잭션 잔액이 완벽하게 맞아도 수익을 부채 감소로 기록할 수 있으며, 이는 순수하게 구문론적인 검사로는 감지되지 않습니다.

다음에 읽어볼 내용

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — 배치 탐지 방식의 대안으로 우도 기반 이상 점수 산출 방식을 제안합니다. Beancount 컴파일러 신호와 결합하여 구조적으로는 유효하지만 통계적으로 이상한 항목을 찾아내는 데 자연스럽게 연결됩니다.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — 신뢰도가 낮은 결정을 더 큰 모델이나 인간에게 라우팅합니다. Beancount 라이트백 에이전트가 컴파일러 피드백 루프 후에도 언제 인간의 검토를 요청해야 하는지에 대한 문제에 직접적으로 답변합니다.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — 이 논문에서 평가한 아키텍처 위에 루프 내 컴파일러 수정 에이전트를 구축하는 데 가장 관련이 깊은 기존 연구입니다.