
Benchouse는 같은 맥락 정보를 제공해 여러 분석 에이전트를 벤치마크한다. 이번에는 오픈소스 분석 에이전트 nao를 평가 세트에 맞춰 개선했으며, 모델 변경과 데이터 설명·정의·응답 규칙 추가를 거쳐 정확도를 49.6%에서 96.5%로 끌어올렸다.
실험에는 오픈소스 분석 에이전트 nao를 사용했다. nao는 맥락 계층을 파일 시스템으로 관리하고, 어떤 종류의 맥락이나 의미 계층과도 함께 사용할 수 있어 스키마만 제공하는 설정부터 문서화된 비즈니스 정의를 제공하는 설정까지 나란히 시험하기에 적합했다. 설정은 간단했다. 평가 프레임워크를 MCP로 연결하고, 맥락은 버전 관리되는 파일로 관리했다.
같은 질문으로 네 가지 설정 비교
평가 세트는 데이터 웨어하우스의 59개 마트 테이블을 대상으로 한 질문 90개로 고정했다. 질문은 세 단계로 나뉘었다.
- 기술형: 무슨 일이 있었나?
- 진단형: 무슨 일이 있었고, 왜 그랬나?
- 처방형: 무슨 일이 있었고, 왜 그랬으며, 무엇을 해야 하나?
질문 다섯 개는 웨어하우스에 없는 정보를 의도적으로 물었다. 에이전트가 이런 질문에 답변을 거부해야 하는지 확인하기 위해서다. 네 가지 설정은 앞선 설정에 정보를 차례로 더하는 방식으로 만들었다.
- 기본 스키마: 웨어하우스를 연결하고 테이블명과 열 이름만 제공했다. 열 설명도 주지 않았다.
nao sync추가: 열 정보, 샘플 행, 프로파일링 정보를 제공했다.- 전체 문서 추가: 테이블, 키, 관계, 동의어, 피해야 할 조인을 설명했다.
- 정의와 응답 규칙 추가: nao의 Recommendations와 Benchouse의 개선 사항을 적용해 명시적인 비즈니스 정의, 답변 방법, 더 명확한 동의어, 수정된 카탈로그 안내를 넣었다. 이 내용은 별도의 학습 세트를 이용해 개발했다.
맥락을 사용자 정의하려면 파일을 편집해야 했다. nao는 지침과 문서, 응답 규칙을 유연하게 추가할 수 있어 에이전트가 아는 내용과 그 정보를 사용하는 방식을 바꿀 수 있었다. 각 설정에는 같은 질문 90개를 세 차례씩 제시해 일관성을 측정했다. 측정 과정은 맥락을 바꾸는 동안 동일하게 유지하기 위해 nao 자체 평가 도구 대신 Benchouse 평가 프레임워크를 사용했다.
모델과 맥락에 따른 결과
가장 큰 첫 차이는 모델에서 나타났다. 처음에는 정확도 개선의 대부분이 더 나은 맥락에서 나올 것이라고 예상했지만, 테이블명과 열 이름만 제공한 기본 스키마에서도 Opus 5.5는 88.2%를 기록했다. Sonnet 5로 같은 설정을 시험하자 정확도는 49.6%였다. 평가에서는 Sonnet이 데이터베이스 스키마를 파악하는 데 어려움을 겪었고, Opus는 사용할 수 있는 도구를 적극적으로 활용했다.
| 설정 | Sonnet 5 정확도 | Sonnet 5 비용/질문 | Opus 5.5 정확도 | Opus 5.5 비용/질문 |
|---|---|---|---|---|
| 기본 스키마 | 49.6% | $0.26 | 88.2% | $0.28 |
nao sync 추가 | — | — | 88.6% | $0.23 |
| 전체 문서 추가 | — | — | 91.4% | $0.24 |
write-context-rules 추가 | — | — | 92.9% | $0.24 |
| 정의와 규칙 추가 | — | — | 96.5% | $0.27 |
nao sync는 데이터베이스 맥락인 테이블과 열 정보를 가져와 에이전트가 사용할 수 있도록 로컬에 저장한다. 이 정보를 더해도 Opus의 정확도는 거의 변하지 않았다. Opus가 이미 데이터베이스 구조를 파악하기 위해 추가 도구 호출을 했기 때문이다. 다만 맥락을 바로 사용할 수 있게 되면서 질문당 비용은 낮아졌다. 정확도 변화는 각 단계에 표시한 퍼센트포인트 기준이다.
전체 문서화로 정확도가 95%에 도달할 것이라는 가설을 세우고 다음 내용을 추가했다.
- 모든 테이블과 열의 설명
- 테이블의 세부 수준, 즉 각 행이 무엇을 나타내는지에 대한 설명
- 기본 키와 외래 키
- 테이블 간 관계
- 테이블과 열의 비즈니스 동의어
- 서로 호환되지 않는 키나 세부 수준의 불일치 등 피해야 할 조인
- 범주와 상태 등 코드화된 필드의 값 목록(열거형)
전체 문서를 제공했을 때 세 차례 시도의 정확도는 91.4%였다. 이어 문서에 nao의 write-context-rules 기능을 적용했다. 단일 시도끼리 비교하면 정확도는 90.6%에서 92.9%로 2.3퍼센트포인트 높아졌고, 질문당 비용은 $0.247에서 $0.239로 소폭 감소했다. 이 단계에서도 95%에는 미치지 못해 남은 오답을 살펴봤다.
오답을 분석해 정의와 규칙 보완
마지막 설정을 만들 때는 평가 질문 90개에 맞춰 개선 사항을 과적합하지 않도록 별도의 질문 210개로 학습 세트를 구성하고, 깨끗한 실행 환경에서 시험했다. 오답 분석에서 개선할 점 네 가지가 드러났다. 에이전트가 요청 없이 데이터 문제를 고치려 하고, 비즈니스 용어가 여러 의미로 해석될 수 있으며, 모호한 맥락이 서로 다른 해석으로 이끌고, 분석 에이전트가 지나치게 앞서 나가 질문의 요점을 놓칠 수 있었다.
첫째, 에이전트는 데이터 문제를 먼저 해결하려 했다. 프로젝트의 RULES.md에는 비즈니스에서 쓰는 수치를 먼저 제시한 다음 한계를 알리고, 대안 수치에는 대안이라고 표시하라고 적었다. 웨어하우스에는 일부 공휴일을 놓치는 공휴일 플래그가 있었고, 문서에도 그 한계가 설명돼 있었다. 에이전트는 이 사실을 알고 매번 자체 달력을 만들었다. 실제 한계를 찾아낸 것이지만, 불완전한 플래그가 비즈니스에서 합의한 공휴일 정의였다.
블렌디드 ROAS에서도 비슷한 일이 있었다. 에이전트는 플랫폼이 광고에 귀속한 수치 대신 매장 매출을 광고비와 비교했다. 타당해 보이는 답도 회의에서 필요한 수치와 다를 수 있다. 필드 설명만으로는 어떤 해석을 먼저 제시해야 하는지 정해지지 않았다.
둘째, 비즈니스 정의와 업계 표준이 다른 지점을 명시했다. 예를 들면 다음과 같다.
- 귀속 매출은 다른 모델을 요청하지 않는 한 플랫폼 보고 수치를 기본값으로 삼고, 서로 겹치는 귀속 주장에 대한 경고를 붙인다.
- 충족률은 납기일이 된 구매 주문 항목을 기준으로 계산한다. 아직 납기일이 되지 않은 항목은 계속 주문 상태로 본다.
- 손실 캠페인은 광고비뿐 아니라 판매된 상품의 원가까지 충당해야 한다.
각 테이블의 관련 문서와 함께 annotations.md 파일의 Definitions 섹션에 정의를 추가했다. 마케팅 테이블에는 손실 캠페인을 다음과 같이 정의했다.
## Definitions
- **Money-losing campaign:** attributed revenue does not cover
ad spend plus the cost of goods sold.
Break-even ROAS = 1 / gross-margin rate.
캠페인 매출이 광고비보다 많더라도 손실이 날 수 있다. 이 차이를 에이전트가 추론하도록 두지 않고 맥락에 명시해야 했다.
셋째, 용어를 명확히 했다. 맥락의 일부 내용이 서로 겹쳐 에이전트를 혼란스럽게 했다. 같은 동의어가 서로 다른 열을 가리키면 에이전트가 선택해야 할 항목이 늘어난다. 오해를 부르는 카탈로그 안내도 잘못된 방향으로 이끌 수 있다. 설명을 더하는 것만큼 표현을 명확히 하는 일이 중요했다. 이에 테이블 주석의 동의어를 수정하고 카탈로그의 오해를 부르는 열 설명을 고쳤다.
넷째, 질문에 먼저 답하도록 했다. 에이전트는 도움이 되려고 하다가 사용자가 다음에 물을 것이라고 예상한 질문에 앞서 답하기도 했다. 벤치마크에서는 우선 질문에 답한 뒤 분석을 더 진행할 수 있도록 했다. 지침은 비즈니스에서 사용하는 수치를 먼저 제시하고, 그 뒤에 대안 수치를 명확히 표시해 제공하라는 것이었다. 요청한 기간과 세부 구분에 맞춰 답하고, 데이터가 없으면 이를 알리며, 핵심 수치를 본문에 넣으라고도 했다. 이 지침은 모든 질문에 적용되도록 프로젝트 공통 RULES.md에 넣었다.
최종 결과와 모델 선택
최종 맥락 설정은 정확도 96.5%, 완전성 100.0%를 기록했다. Opus의 전체 문서 설정보다 5.1퍼센트포인트, 기본 스키마 설정보다 8.6퍼센트포인트 높은 수치다. 세 차례 모두 정답을 낸 질문의 비율도 77.6%에서 92.9%로 높아졌다.
최종 설정의 질문당 비용은 nao sync만 사용한 설정보다 높았지만, 정답 하나당 비용은 기본 설정보다 낮았다. 여러 정의와 규칙을 함께 시험했으므로 각각의 정의, 추천 사항, 규칙이 정확도를 얼마나 높였는지 따로 분리해 계산할 수는 없다.
최종 맥락을 그대로 두고 모델 설정만 바꿔 Sonnet 5.5도 시험했다. Sonnet 5.5는 정확도 92.9%를 기록했고, 정답 하나당 비용은 $0.164였다. C3 Opus의 첫 시도 정확도는 94.1%였다. 이 결과는 더 폭넓은 모델 비교가 필요하다는 점을 보여준다. 질문당 비용은 $0.27에서 $0.14로 48% 줄었지만, 정확도는 3.6퍼센트포인트 낮아졌다.
| 설정 | Sonnet 5 정확도 | Sonnet 5 비용/질문 | Sonnet 5.5 정확도 | Sonnet 5.5 비용/질문 | Opus 5.5 정확도 | Opus 5.5 비용/질문 |
|---|---|---|---|---|---|---|
| 기본 스키마 | 49.6% | $0.26 | — | — | 88.2% | $0.28 |
nao sync 추가 | — | — | — | — | 88.6% | $0.23 |
| 전체 문서 추가 | — | — | — | — | 91.4% | $0.24 |
write-context-rules 추가 | — | — | — | — | 92.9% | $0.24 |
| 정의와 규칙 추가 | — | — | 92.9% | $0.14 | 96.5% | $0.27 |
한 번의 변경으로 모든 문제가 해결되지는 않았다. 모호한 동의어, 잘못된 설명, 명시되지 않은 정의, 사용자가 물었어야 한다고 에이전트가 판단한 질문에 답하는 행동이 각각 영향을 미쳤다. 실제 질문으로 시작해 오답을 읽고, 각 실수의 원인을 찾아 맥락을 개선한 뒤 다시 시험하는 접근을 권한다. 이후 모델 선택을 다시 살펴보면 비용을 줄일 수 있을지 확인할 수 있지만, 비용뿐 아니라 답변에 어떤 변화가 생기는지도 점검해야 한다.
nao는 설정하기 쉽고 맥락을 유연하게 다룰 수 있어 자체 데이터와 맥락을 시험해 보려는 경우 사용해 볼 만한 도구라고 소개됐다. nao 시작하기.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요