제가 디버깅한 대부분의 에이전트 실패 사례는 추론(reasoning)의 실패가 아니었습니다. 모델은 추론을 잘 해냈습니다. 단지 도구 설명(tool description)이 모델에게 필요한 정보를 알려주지 않았기 때문에 잘못된 도구를 선택했을 뿐입니다.

이는 충분히 논의되지 않은 문제이며, 통합(integration)을 더 많이 추가할수록 상황은 악화됩니다. 저희가 배운 내용은 다음과 같습니다.

설정 (The setup)

에이전트가 네 가지 정도의 캘린더 관련 도구를 사용할 수 있다고 가정해 봅시다:

[
  { "name": "calendar_create_event",   "description": "Creates a calendar event" },
  { "name": "calendar_quick_add",      "description": "Adds an event from text" },
...

이제: "목요일에 Sarah와 30분간 미팅 예약해줘."라고 요청합니다.

어떤 것을 선택해야 할까요? 당신도 모르며, 모델은 알 수 없는 컨텍스트(context)를 당신은 가지고 있습니다. 모델은 하나를 선택할 것이고, 아마 60% 정도의 확률로 작동하겠지만, 틀렸을 때의 실패는 조용히 일어납니다. 즉, 아무도 일주일 동안 알아차리지 못하는 잘못된 시스템에 이벤트가 생성되는 식입니다.

저희 에이전트 실패 사례의 약 40%는 추론이 아닌 도구 선택(tool selection) 문제로 거슬러 올라갔습니다. 이는 놀라운 사실이었으며, 저희가 엔지니어링 시간을 어디에 투입할지를 바꾸어 놓았습니다.

OpenAPI 스키마(schemas)가 충분하지 않은 이유

스키마는 도구가 무엇을 수용하는지를 알려줍니다. 하지만 다음 사항들은 알려주지 않습니다:

• 도구의 용도 — 시그니처(signature)가 아닌 유스케이스(use case)
• 유사해 보이는 네 가지 인접 도구와 비교했을 때 언제 사용하는 것이 적절한지
• 가역성(reversible) 여부 — 실행 취소(undo)가 가능한지, 그리고 어떻게 가능한지
• 비용 — 호출 제한(rate-limited)이 걸린 호출과 무료 호출은 동일하게 매력적이어서는 안 됩니다
• 전제 조건 — 사용자의 캘린더가 먼저 연결되어 있어야 하는지 등

문서화(Documentation) 역시 이를 제공하지 않습니다. 왜냐하면 문서는 이미 어떤 제품과 통합할지 알고 있는 인간을 위해 작성되기 때문입니다. 하지만 모델은 제품들 사이에서 선택을 하고 있습니다.

에이전트를 위한 설명은 어떤 모습이어야 하는가

저희가 수렴한 템플릿은 다음과 같습니다:

name: calendar_create_event
purpose: >
  Create an event on the user's primary Google Calendar when you already
...

명시적인 리다이렉트 (redirects)가 포함된 do_not_use_when 블록이 대부분의 역할을 수행하고 있습니다. 이것은 해당 도구를 설명하는 것이 아니라, 모델이 불확실해하는 지점인 이 도구와 주변 도구 사이의 경계를 설명하고 있는 것입니다.

대규모 생성 (Generating these at scale)

이것들을 수동으로 작성하는 것은 수십 개의 도구를 넘어 확장하기 어렵습니다. 우리의 루프(loop)는 다음과 같습니다:

1. 모델을 사용하여 스키마 (schema)와 존재하는 모든 문서로부터 초안을 생성합니다.
2. 이를 배포합니다. 결과물은 평범할 것입니다.
3. 에이전트에게 요청된 내용과 에이전트가 선택한 내용과 함께 모든 선택 사항을 기록합니다.
4. 선택이 잘못되었을 때, 프롬프트 (prompt)를 수정하지 마세요. 대신 선택되었어야 할 도구와 실제로 선택된 도구의 설명을 수정하세요.
5. 시간이 흐름에 따라 설명은 시스템이 저지른 모든 실수의 기록이 됩니다.

def record_misselection(task, chosen_tool, correct_tool):
    # 수정 사항은 시스템 프롬프트가 아니라 도구 메타데이터 (metadata)에 반영됩니다.
    # 시스템 프롬프트 수정은 일반화되지 않지만, 설명 수정은 일반화됩니다.
...

여기서 5단계가 가장 중요합니다. 모든 본능은 시스템 프롬프트에 규칙을 추가하여 선택 오류를 수정하라고 말합니다. 하지만 이를 저항해야 합니다. 프롬프트 수정은 전역적 (global)이며, 서로 충돌하고, 모델 업그레이드 시 유지되지 않습니다. 반면 설명 수정은 관련된 도구에 국한된 지역적 (local) 수정이며, 서로 결합 (compose)될 수 있습니다.

저비용의 승리: 전송 전 가지치기 (prune before you send)

이와 관련하여 실제로 비용을 절감할 수 있는 방법이 있습니다. 루프의 매 단계마다 모든 도구 스키마를 보내지 마세요. 스키마는 매 반복마다 다시 전송되기 때문에 (실행당 한 번이 아님), 토큰 소비의 큰 비중을 차지할 수 있습니다.

def relevant_tools(context, all_tools, k=8):
    # 저비용 사전 필터링 — 현재 목표와 각 도구의 `purpose` 필드 간의
    # 임베딩 유사도 (embedding similarity)를 사용
...

컨텍스트 (context) 내의 도구 수가 적을수록 선택 정확도도 높아지므로, 이 방법은 두 가지 측면에서 도움이 됩니다. 대부분의 프레임워크는 에이전트에게 처음부터 모든 것을 전달하도록 권장하지만, 도구가 12개 이상인 경우에는 그것이 잘못된 기본 설정입니다.

더 중요한 점은

업계는 모델 품질(model quality)과 통합 개수(integration count)를 두고 경쟁하고 있습니다. 하지만 현재 에이전트의 신뢰성(reliability)이 실제로 어디에서 오는지에 대한 답은 둘 다 아닙니다.

시맨틱 레이어(semantic layer) — 즉, 각 도구가 무엇을 의미하는지, 언제 적용되는지, 그리고 이웃한 도구들과 어떻게 다른지에 대한 정보 — 는 아무도 기능(feature)으로 출시하지 않는, 매력적이지 않은 큐레이션 작업입니다. 또한 저희의 경험에 따르면, 이는 데모에서만 잘 작동하는 에이전트와 관리 없이도 스스로 작동하는(unattended) 에이전트를 가르는 차이점입니다.

만약 제가 다시 시작한다면, 이를 단순히 거쳐 가야 할 인프라(infrastructure)가 아니라, 첫날부터 핵심 제품(core product)으로 다룰 것입니다.

DeskFerry를 구축 중 — 1,500개 이상의 통합(integrations)을 지원하는 에이전트를 만들고 있으며, 이것이 저희가 이 문제에 관심을 갖게 된 계기입니다. 아래에 질문을 남겨주세요.