도구 호출 — 모델은 무엇을 보고 고를까 · Prompt Quest

도구 정의도 프롬프트야

도구를 노출하는 일은 모델에게 “이런 행동도 할 수 있어”라고 알려주는 지시야. 모델은 도구를 부를지, 어떤 인수를 넣을지, 결과를 답에 어떻게 엮을지 결정해. 도구 호출 고장의 상당수는 결국 프롬프트 고장이야. 도구의 이름, 설명, 입력 스키마가 모델의 선택을 움직이거든.

모델이 실제로 읽는 항목

도구 이름 — search_documents, create_ticket처럼 동사나 동사와 명사로 지어.
설명 — 무엇을 하며 언제 써야 하는지 짧고 분명하게 적어. 가장 자주 대충 쓰는 필드지만 작은 프롬프트처럼 다뤄야 해.
입력 스키마 — JSON Schema와 각 필드 설명이 모두 모델에게 보여.
사례 — 일부 제공업체는 예시 도구 호출을 지원해. 쓰임새가 바로 드러나지 않는 도구에 붙여.

흔한 실수

언제 써야 하는지 없는 한 줄짜리 설명.
같은 일을 서로 다른 방식으로 하는 겹치는 도구.
설명 없이 id, data라고만 붙인 필드.
도구가 실패했을 때 무엇을 할지 없는 정의.

Code

설명을 충실히 쓴 도구·json

{
  "name": "search_orders",
  "description": "Find a customer's orders by customer_id, date range, or status. Use this when the user mentions an order, a delivery, a refund, or a tracking number. Do not use it for general account questions.",
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string", "description": "Internal customer ID, format CUST-NNNNNN."},
      "status": {"type": "string", "enum": ["pending", "shipped", "delivered", "returned"]},
      "date_from": {"type": "string", "format": "date"}
    },
    "required": ["customer_id"]
  }
}

도구 호출 — 모델은 무엇을 보고 고를까

도구 정의도 프롬프트야

모델이 실제로 읽는 항목

흔한 실수

Code

External links

Exercise

Progress

댓글 0