저는 작은 모델이 도구(tool)를 호출하는 과정에서 정말 힘든 시간을 보냈습니다. Claude에게 제 설정을 담당하게 하고, 도구 호출을 개선하기 위한 다양한 옵션을 테스트할 스크립트를 작성하도록 했습니다. 이것은 매우 잘 작동했습니다. 제가 시킨 것은 각 도구를 모의(mocked)하는 파이썬 스크립트(만약 이게 무슨 뜻인지 모르신다면 걱정하지 마세요, 여러분의 AI 도구가 알아서 합니다)를 작성하는 것이었습니다. 그런 다음 ollama 파이썬 라이브러리를 사용하여 다양한 LLM을 호출하고 파이썬 API를 통해 도구를 노출했습니다. 그리고 각 LLM에 프롬프트를 실행하여 예상되는 도구를 호출하는지 확인했습니다. 이미 알고 있었던 것처럼 실패율이 매우 높았습니다. Claude는 도구 호출의 매개변수(parameters)를 변경했고, 100% 성공률을 얻을 때까지 테스트를 재실행했습니다. 요약하자면 다음과 같습니다: 도구가 많을수록 컨텍스트가 많아지고, 작은 LLM이 어떤 도구를 호출할지 결정하기 어려워질수록 오류가 많이 발생합니다. 그래서 저는 도구의 개수를 줄이고 여러 도구를 하나로 그룹화했습니다. 더 엄격한 도구 매개변수는 작은 LLM에게 규칙을 더 주의 깊게 따르도록 요구하는데, 작은 LLM은 이 부분에서 능숙하지 못해서 오류가 더 많이 발생합니다. 일반적인 오류 메시지는 작은 LLM이 계속 벽에 머리를 박는 것처럼 같은 것을 약간 다른 설정으로 반복해서 시도하게 만들어 오류를 더 많이 발생시킵니다. 저는 에이전트가 할 수 있는 공통적인 것들을 파악하여 도구를 줄이고 여러 단계를 하나로 결합했습니다. 이는 비즈니스 로직을 코드로 옮기는 데 도움이 될 뿐만 아니라 속도를 극적으로 높여줍니다. 또한 에이전트가 올바른 도구를 선택할 확률도 높였습니다. 저는 (음, Claude가 만든) 도구들이 매개변수에 대해 더 관대한(lenient) 태도를 갖도록 만들었습니다. 즉, 순서가 달라도 괜찮게 한 것입니다. 이것은 성공률에 엄청난 영향을 미쳤습니다. 도구들은 실패했을 때

저는 단지 5개의 도구만 노출하고 에이전트가 평소에 필요로 하는 모든 작업을 수행할 수 있도록 로컬 도구를 만들었습니다. 기존에는 약 100개의 도구가 있었습니다. 이것은 컨텍스트 크기에도 즉각적인 영향을 미쳤습니다. 이전에는 50k의 컨텍스트를 사용했지만, 이제는 몇 k 수준으로 줄어들었습니다. 그리고 제 파이썬 앱은 하나의 도구 호출을 통해 결과를 페이지네이션(paginating)하는 것을 포함한 여러 API 호출을 수행할 수 있게 하여 시간을 약 10%까지 단축시켰습니다. 물론 LLM이 작아질수록 도구를 사용하는 데 더 어려움을 겪게 될 것입니다. 저는 아직 제가 가장 좋아하는 작은 모델인 Gemma 4 A2B로 테스트하지는 않았지만, 이러한 기법들은 잘 스케일 다운(scale down)될 것이라고 확신합니다. submitted by /u/newz2000 [link] [comments]