Tool Contract Test

Tool 은 바뀌어. Schema 는 어긋나. 모델은 계속 새 버전이 나와. Contract 가 어긋났을 때 깨져주는 test 가 없으면, agent 는 누가 알아챌 때까지 몇 주를 조용히 망가진 채로 굴러가. Tool contract test 는 살 수 있는 보험 중에 제일 싼 거야.

모양 세 개로 시작해:

Schema 검사: 모든 tool 정의가 올바른 JSON Schema 이고, provider SDK 를 경고 하나 없이 통과하는지. 빠른 unit test 하나면 돼.
선택 정확도: prompt 와 불려야 마땅한 tool 을 짝지어 fixture 파일로 만들어. 작고 싼 모델로 각 prompt 를 돌려서 tool 이름을 확인하고, 맞은 비율을 기록해. 이건 모델이 얼마나 똑똑한지 재는 게 아니야. 네 description 이 아직 모델을 제대로 이끌고 있는지를 재는 거지.
인자 정확도: 더 작은 fixture 묶음에는 핵심 인자까지 확인해. 모델이 user 메시지에서 customer_id="C-9" 를 제대로 뽑아 넘겼나? 날짜 형식은 맞췄나? 인자 test 가 description 이 망가진 걸 잡아줘.

함정은 과하게 test 하는 거야. Tool call 사이에 모델이 쓴 문장의 정확한 단어까지 확인하지 마 — release 마다 의미 없이 흔들리니까. 확인할 건 구조 야. 어느 tool 을 골랐고, 인자가 뭐였고, loop 가 끝났는지. 문장을 확인하는 건 흔들려도 괜찮다고 미리 정해둔 end-to-end test 에 맡겨.

Tool description 이나 schema 가 바뀔 때 CI 에서 돌리고, provider 의 최신 모델로 밤마다 한 번 더 돌려. 모델 업그레이드가 선택 정확도를 슬그머니 바꿔놓은 걸 처음 잡아내는 순간, 이게 왜 진짜 test 였는지 알게 될 거야.

Code

가장 작은 fixture 기반 test·python

import pytest, json

FIXTURES = json.load(open("tests/tool_fixtures.json"))

@pytest.mark.parametrize("prompt,expected_tool", [(f["prompt"], f["tool"]) for f in FIXTURES])
def test_tool_selection(prompt, expected_tool, agent):
    resp = agent.one_turn(prompt)
    actual = next((b.name for b in resp.content if b.type == "tool_use"), None)
    assert actual == expected_tool, f"{prompt!r}: expected {expected_tool}, got {actual}"

Fixture 파일 모양·json

[
  {"prompt": "where is order 9912?", "tool": "search_orders"},
  {"prompt": "show me the new arrivals in shoes", "tool": "search_catalog"},
  {"prompt": "refund order 9912 — wrong size", "tool": "propose_refund"},
  {"prompt": "what's your return policy?", "tool": null}
]

Exercise

Agent 하나에 prompt 10 개짜리 fixture 파일을 만들어. 'tool 없이 그냥 말로 답하는 게 정답' 인 prompt 도 세 개 넣어. Suite 를 돌려서 정확히 고른 비율을 기준선으로 적어둬. 이제 tool description 하나를 바꾸고 다시 돌려 — 비율이 움직이는 걸 봐. 그 움직임이 네 test 가 살아 있다는 증거야.

Code

External links

Exercise

Progress

댓글 0