에이전트가 도구 호출에 데이터를 복사할 때 숫자를 누락시키는 문제와 파일 경로를 통한 해결 방법

저는 백테스트를 확인하는 MCP 서버를 운영하고 있습니다. 이 서버는 전략의 일일 수익률을 입력받아 샤프 비율(Sharpe ratio)이 의미를 가지려면 몇 년간의 기록이 필요한지 등을 알려줍니다.

가장 당연한 사용 방법은 수익률 데이터를 채팅창에 붙여넣고 에이전트가 이를 도구로 전달하게 하는 것입니다. 하지만 이것이 최악의 방법으로 판명되었습니다. 여기에 측정 결과를 공유합니다.

설정 (The setup)

세 가지 질문을 던졌으며, 각 질문은 전체 감사 체인(audit chain)을 필요로 했습니다. 예를 들어, "이 수익률 시리즈가 95% 신뢰 수준에서 샤프 비율이 1.0을 넘기려면 몇 년간의 기록이 필요한가?"와 같은 질문입니다. 이 시리즈는 400개, 504개, 그리고 756개의 일일 수익률로 구성되어 있었습니다. 각 질문은 동일한 모델(gpt-5.4-mini)로 3번씩 요청되었으므로, 팔(arm)당 총 9회 실행되었습니다. 정답(ground truth)은 도구가 실행하는 것과 같은 로컬 계산 결과이므로, 답변은 맞거나 (2% 이내), 아니면 틀렸습니다.

세 가지 방식(Three arms):

1. 기존 도구 사용 및 수익률 붙여넣기. 원-콜 감사 도구(one-call audit tool)가 존재하기 전의 서버 방식으로, 에이전트가 여러 검증기(validators)를 자체적으로 연결해야 했습니다.
2. 원-콜 감사 도구 사용 및 수익률 붙여넣기. 시리즈가 JSON 배열 형태로 프롬프트에 포함되어 있고, 에이전트가 이를 도구 호출에 복사합니다.
3. 원-콜 감사 도구 사용 및 파일 경로 지정. 시리즈가 CSV 파일로 존재하며, 프롬프트에서 파일을 명시하고 도구가 해당 파일을 읽습니다.

결과 (The result)

붙여넣기 방식이 잘못된 이유 (What went wrong when it pasted)

흥미로운 부분은 붙여넣기 방식으로 실행했을 때 어떻게 실패했는지입니다. 756개 수익률 질문의 경우, 세 가지 붙여넣기 실행 모두 동일하게 틀린 답변(0.1718년)을 제시했습니다. 정답은 0.1452년이었습니다. 이는 세 번에 걸쳐 발생한 세 가지 다른 실수가 아니라, 한 가지 동일한 실수였습니다.

호출로 값이 누락될 때 발생하는 상황이 바로 이겁니다. 모델은 756개의 숫자를 출력 토큰으로 다시 타이핑합니다. 그 과정에서 일부를 건너뛰었고, 도구는 잘못된 시리즈에 대해 정확한 답을 충실히 계산했으며, 에이전트는 이를 완전한 확신과 함께 보고했습니다. 오류가 발생하지 않았습니다. 만약 제가 실제 값을 알지 못했다면, 저는 그것을 믿었을 겁니다.

붙여넣기(Pasting)도 비용이 듭니다. 모든 숫자는 두 번 지불됩니다. 프롬프트의 입력으로 한 번, 모델이 도구 호출을 작성할 때 출력으로 한 번입니다. 붙여넣기로 실행한 단 한 번의 작업에 대해 질문 하나당 76,930 토큰이 사용되었습니다.

파일 아크(file arm)에서 발생한 오류는 달랐습니다. 에이전트는 388을 답변했는데, 이는 연도(years)를 물었음에도 불구하고 observations (약 1.54년 × 252 거래일)에 보고된 올바른 답이었습니다. 데이터 손실이 아니라 단위 오류였습니다.

제가 변경한 사항

• 감사 도구(audit tool)는 로컬 서버에서 returns_file (CSV 파일 경로)를 받습니다. 숫자를만 읽고, 파일 크기를 제한하며, 컨텍스트에 파일 내용을 에코(echoing)하는 대신 행 위치별로 오류를 보고합니다.
• 도구 설명에는 긴 시리즈가 파일 형태로 제공되어야 한다고 명확하게 명시했습니다.
• 호스팅된 버전은 사용자의 디스크를 읽을 수 없으므로, 가장하는 대신 파일 입력을 거부합니다.

이 테스트의 한계점

이것은 작은 모델이며, 아크(arm)당 9회 실행되었고, 합성 시리즈에 대한 것입니다. 저는 이 경우 Claude 모델을 사용하지 않았습니다. 그러니 '붙여넣기가 정확도를 정확히 55% 떨어뜨린다'가 아니라, '이러한 실패는 실제적이고 쉽게 발생할 수 있다'로 읽어주십시오. 다른 모델로 다시 실행하고 싶다면, 실행 기록과 작업 코드는 리포지토리에 있습니다.

제가 얻은 일반적인 교훈은 다음과 같습니다: 도구가 많은 데이터를 필요로 한다면, 모델이 그 데이터를 직접 운반하게 하지 마십시오. 참조(경로, ID, URL)를 전달하고 도구가 이를 가져오게 하세요. 모델은 무엇을 계산할지 결정하는 것은 잘하지만, 복사기 역할은 못합니다.

여러분도 긴 JSON, CSV 행 또는 로그와 같은 다른 종류의 데이터에서 비슷한 것을 본 적이 있습니까? 더 큰 모델의 길이 임계값이 어디에 위치하는지 궁금합니다.