3가지 실제 에이전트 작업으로 저가형 vs 고가형 LLM을 테스트했습니다. 저가형 모델이 매번 승리했습니다.

저는 3가지 실제 에이전트 (Agent) 작업에 걸쳐 저가형 vs 고가형 LLM (Large Language Models)을 테스트했습니다. 저가형 모델이 매번 승리했습니다. 모두가 당신에게 감당할 수 있는 최선의 모델을 사용하라고 말합니다. 저는 데이터를 통해 그 가설을 테스트할 툴킷 (Toolkit)을 구축했고, 그 결과는 저를 놀라게 했습니다. 지난 몇 주 동안, 저는 세 가지 서로 다른 LLM 기반 에이전트를 구축하고 각 에이전트에 대해 구조화된 평가 (Structured evaluations)를 실행했습니다. 동일한 골든 데이터셋 (Golden datasets)을 사용하여 정확도 (Accuracy), 비용 (Cost), 지연 시간 (Latency) 측면에서 모델들을 비교했습니다.

설정 (THE SETUP)
저는 어떤 에이전트 함수든 감싸서(wrap) 레이블이 지정된 데이터셋에 대해 실행하고 비교 테이블을 생성하는 CLI 도구를 구축했습니다. 에이전트를 변경할 필요는 없습니다. 인터페이스를 조정하는 얇은 래퍼 (Thin wrapper)를 작성하고, 도구를 테스트 케이스에 연결하기만 하면 결과를 얻을 수 있습니다. 저는 세 가지 에이전트 유형을 테스트했습니다:

1. GitHub 이슈 분류기 (GitHub issue classifier) — Streamlit의 오픈 소스 리포지토리에서 이슈 텍스트를 가져와 버그 (bug), 기능 요청 (feature_request), 질문 (question), 또는 불완전함 (incomplete)으로 분류합니다. 30개의 수동 레이블링된 이슈를 사용했습니다.
2. 감성 분석기 (Sentiment analyzer) — SST-2의 영화 리뷰 문장에 대해 긍정/부정 이진 분류를 수행합니다. 의도적으로 모호하게 만든 10개(비꼬기, 이중 부정, 혼합된 감정)를 포함하여 총 40개의 케이스를 사용했습니다.
3. RAG 질의응답 (RAG question-answering) — 검색 증강 생성 (Retrieval-augmented generation)을 사용하여 미국 헌법에 관한 질문에 답합니다. 쉬움, 중간, 어려움 난이도에 걸친 30개의 질문을 사용했습니다. RAG 검색을 사용한 경우와 사용하지 않은 경우를 모두 테스트했습니다.

모든 테스트는 동일한 워크플로우 (Workflow)를 사용했습니다: 수동으로 검증된 레이블로 골든 데이터셋을 구축하고, 각 모델을 대상으로 실행한 뒤 비교합니다.

결과 1: 분류 작업에서 Haiku가 Sonnet을 능가함
GitHub 이슈 분류, 30개의 Streamlit 이슈:

• Haiku — 30/30 (100%), 평균 지연 시간 1.7초, 오류 0개
• Sonnet — 29/30 (96.7%), 평균 지연 시간 3.3초, 오류 1개

Haiku — 비용이 대략 3분의 1 수준인 모델 — 가 더 정확하고 더 빨랐습니다. Sonnet의 단 한 번의 실수는 잘못 분류된 이슈였던 반면, Haiku는 모든 이슈를 정확히 맞혔습니다. 이는 30개의 LangChain 이슈에 대한 별도의 이전 테스트에서도 유지되었으며, 해당 테스트의 어려운 모호한 하위 집합에서 Haiku는 87%, Sonnet은 80%를 기록했습니다.

결과 2: 무료 로컬 모델이 감성 분석(Sentiment Analysis)에서 유료 API와 대등한 성능을 보였습니다.

감성 분석 (Sentiment analysis), 40개의 SST-2 문장:

• DistilBERT (로컬) — 40/40 (100%), 비용: 무료, 평균 지연 시간(avg latency) 0.1s
• Haiku — 40/40 (100%), 비용: $0.006, 평균 지연 시간 0.9s
• Sonnet — 40/40 (100%), 비용: $0.019, 평균 지연 시간 1.5s

제 노트북에서 로컬로 실행되는 250MB 크기의 모델이 비꼬는 표현(sarcasm)이나 이중 부정(double negatives)이 포함된 모호한 사례를 포함하여 모든 경우에서 두 Claude 모델과 대등한 성능을 보였습니다. 이 모델은 Haiku보다 9배, Sonnet보다 15배 더 빨랐습니다. 이 작업의 경우, API 비용을 지불하는 것은 아무런 이득이 없습니다. 두 Claude 모델은 2개의 엣지 케이스(edge cases)에서 DistilBERT와 의견이 달랐지만(각각 1개씩), 세 모델 모두 100%를 기록했습니다. 이는 골든 데이터셋(golden dataset)이 해당 사례들을 여러 개의 허용 가능한 정답이 있는 모호한 사례로 올바르게 표시했기 때문입니다.

결과 3: 잘 알려진 콘텐츠에서는 RAG가 정확도를 저하시켰습니다.

미국 헌법 Q&A, 30개 질문, 4가지 모델 변형:

• RAG + Haiku — 80.0%, 평균 지연 시간 1.7s
• Direct Haiku (RAG 미사용) — 96.7%, 평균 지연 시간 1.3s
• RAG + Sonnet — 80.0%, 평균 지연 시간 2.2s
• Direct Sonnet (RAG 미사용) — 93.3%, 평균 지연 시간 1.9s

이것은 가장 놀라운 발견이었습니다. 검색(retrieval)을 추가하는 것이 두 모델 모두의 성능을 악화시켰습니다. RAG+Haiku는 80%를 기록한 반면, Direct Haiku는 96.7%를 기록했습니다. 그 이유는 다음과 같습니다. 검색기(retriever)가 올바른 문서 청크(document chunks)를 가져오는 데 실패했을 때, 모델은 이미 알고 있는 지식을 사용하는 대신 "이 컨텍스트에서는 답변할 수 없습니다"라고 올바르게 답변했습니다. 5건의 RAG 실패는 모두 검색 실패였습니다. 모델이 환각(hallucination)을 일으키기를 거부한 것이며, 이는 좋은 동작이지만, RAG가 모델의 지식을 증강(augmenting)하는 대신 오히려 제약했다는 것을 의미합니다.

모델의 학습 데이터에 이미 포함되어 있는 잘 알려진 콘텐츠의 경우, RAG는 순손실(net negative)입니다. RAG는 지연 시간을 늘리고, 비용을 추가하며(검색된 컨텍스트로 인한 더 많은 입력 토큰), 모델이 이미 가지고 있는 정보를 숨김으로써 정확도를 떨어뜨립니다. RAG는 모델이 정보를 모를 때, 즉 독점 문서, 최신 데이터, 내부 지식 베이스와 같은 경우에 도움이 됩니다. 공개적이고 잘 확립된 콘텐츠에 대해서는 오히려 해가 됩니다. 또한, Haiku가 다시 한번 Sonnet을 이겼습니다.

Direct Haiku (96.7%)는 비용이 3분의 1 수준임에도 불구하고 Direct Sonnet (93.3%)보다 뛰어난 성능을 보였습니다.

내가 배운 점
"더 비싼 모델이 더 정확하다"는 특정 작업에서는 틀린 말입니다. 일반적인 벤치마크(Benchmarks)에서는 Sonnet이 Haiku보다 앞서지만, 제가 테스트한 모든 특정 작업에서는 Haiku가 Sonnet과 대등하거나 오히려 더 나은 성능을 보였습니다. 모델의 일반적인 능력이 당신의 특정 에이전트(Agent)에서의 성능을 예측하지는 않습니다. 직접 측정해야 합니다. 모델 선택은 가정이 아닌 데이터에 기반해야 합니다. 대부분의 팀은 가장 비싼 모델이 가장 정확할 것이라고 가정하며, 감당할 수 있는 가장 비싼 모델을 기본값으로 선택합니다. 4개의 데이터셋과 3가지 작업 유형 전체에서, 가장 저렴한 옵션이 일관되게 가장 좋았습니다. 이것이 보편적인 진리는 아닙니다. Sonnet이나 Opus가 진정으로 Haiku보다 뛰어난 성능을 보이는 작업도 있을 것입니다. 핵심은 테스트 없이는 알 수 없다는 점입니다.

RAG가 항상 정답은 아닙니다. AI 엔지니어링의 기본 가정은 "정확도를 높이기 위해 RAG를 추가하자"입니다. 잘 알려진 도메인에서는 이것이 역효과를 냅니다. RAG를 사용할지 여부에 대한 아키텍처 결정은 가정이 아닌 테스트를 거쳐야 합니다.

평가에서 가장 어려운 부분은 "정답"을 정의하는 것입니다. 초기 테스트에서 발생한 4가지 "실패" 중 3가지는 레이블링(Labeling) 문제로 밝혀졌습니다. 즉, 모호한 사례, 현실을 포괄하지 못하는 카테고리, 또는 링크 뒤에 있는 정보에 접근하지 않았다는 이유로 모델에 벌점을 주는 등의 문제였습니다. 평가 도구(Eval tooling) 자체는 기계적으로 잘 작동했습니다. 쓰레기 데이터(Garbage labels)를 넣으면 쓰레기 결과(Garbage results)가 나옵니다.

도구
평가 툴킷(Evaluation toolkit)을 오픈 소스로 공개했습니다: github.com/aimvik07/agent-eval
설치: pip install agt-eval
세 가지 명령어:
agent-eval probe config.py — 에이전트가 어디에서 실패하는지 찾습니다. 정확도, 실패 목록, 카테 카테고리 분포를 보여줍니다.
agent-eval compare config.py — 모델을 나란히 비교합니다. 정확도, 비용, 지연 시간(Latency), 일대일 불일치 사항을 보여줍니다.
agent-eval gate config.py — 퇴보(Regressions)를 포착합니다. 저장된 기준점(Baseline)과 비교하여 정확도가 떨어지면 종료 코드 1을 반환합니다.

에이전트 함수를 감싸는 Python 설정 파일(config file)을 작성하고 이를 JSON 골든 데이터셋(Golden dataset)으로 지정하면 됩니다. 나머지는 툴킷이 처리합니다.

이것은 다양한 작업 유형에 대해 완전 일치(exact match), 부분 일치(substring match), 그리고 사용자 정의 비교 함수(custom comparison functions)를 지원합니다. 이것은 스타트업이나 제품이 아니라, 저의 개인적인 워크플로우를 위해 직접 만든 개인용 도구입니다. 여러분에게 유용하다면 사용해 주세요. 만약 고장 난 부분이나 누락된 것을 발견하신다면, 이슈(issue)를 생성해 주세요.