Why Your LLM Agent Gives a Different P-Value Every Time (And What to Build Instead)

개요

LLM 에이전트가 통계 분석 시 매번 다른 p-value를 도출하는 문제를 해결하기 위해, LLM은 분석 방법 선택만을 담당하고 실제 계산은 검증된 결정론적 플러그인 엔진이 수행하는 StatGuard Agent 아키텍처를 제안한다.

주요 내용

• LLM 기반 통계 분석의 불안정성: 동일한 데이터와 프롬프트로 LLM에 분석을 요청했을 때, LLM이 수행하는 가정 검사 여부나 통계 방법 선택의 무작위성 때문에 매번 다른 p-value 및 분석 결과가 도출될 수 있다. 이는 특히 연구나 규제 관련 데이터 분석에서 심각한 문제로 이어진다.
• 기존 해결책의 한계: LLM 실행을 재현 가능하게 만드는 것(replayability)은 동일한 코드가 실행되었음을 보장하지만, 올바른 분석이 수행되었음을 보장하지는 못한다.
• StatGuard Agent 아키텍처:
• LLM Supervisor: 사용자의 자연어 요청을 받아 데이터 확인, 분석 방법 선택 등 추론 및 의사결정 역할을 수행한다.
• Deterministic Plugin Engine: LLM이 선택한 분석 방법을 기반으로 실제 통계 계산을 수행한다. 이 플러그인들은 Scipy/Statsmodels 등과 교차 검증되어 결과가 항상 동일하게 나온다.
• Claims Ledger + Gate: 모든 계산 결과는 구조화된 '클레임(claim)' 형태로 기록되며, LLM은 실제 숫자값이 아닌 클레임 ID를 참조하여 최종 보고서를 생성한다. 이를 통해 LLM이 임의로 숫자를 변경하거나 허위 정보를 생성하는 것을 방지한다.
• 핵심 설계 원칙: LLM은 포인터, 값은 엔진이: LLM은 분석 방법을 선택하는 '포인터' 역할을 하고, 실제 숫자, 날짜, 통계값 등의 '값'은 LLM이 직접 생성하는 것이 아니라 결정론적 엔진이 생성하여 기록한다.
• 검증 및 평가:
• 플러그인 카펫 벤치마크: 각 플러그인이 Scipy/Statsmodels와 동일한 결과(ground truth)를 생성하는지 독립적으로 검증한다.
• 종단 간(End-to-End) 에이전트 벤치마크: LLM 감독 하의 전체 파이프라인이 올바른 플러그인을 선택하고, 오류 없이 최종 답에 도달하며, 모든 보고된 숫자가 검증된 플러그인 실행에서 비롯되었는지, 그리고 최종 결과가 정확한지 평가한다.
• 향후 로드맵: 더 많은 통계 플러그인 추가(LMM, ANOVA, Survival Analysis 등), 모호한 프롬프트에 대한 명확화 루프 도입, Jupyter 노트북 통합(cell magic), 플러그인 스케일링을 위한 라우터 개선 등을 계획하고 있다.

시사점

StatGuard Agent는 LLM의 유연성과 결정론적 계산 엔진의 신뢰성을 결합하여, 통계 분석과 같은 정확성이 중요한 분야에서 LLM 기반 시스템의 신뢰성과 재현성을 획기적으로 향상시킬 수 있는 실용적인 아키텍처를 제시한다. 이 'LLM은 포인터, 값은 엔진이'라는 원칙은 구조화된 수치 데이터를 생성하는 모든 에이전트 시스템에 적용될 수 있다.