AI / LLM
Tool calls: тест на воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт скажи или напиши полный ответ по памяти прежде, чем открыть эталон — именно усилие припоминания закрепляет механизм.
Восстанови ядро механизмов юнита — контракт round-trip, границу доверия при валидации, защиту от runaway, параллелизм, tool_choice и токеновую стоимость схемы — не подглядывая в урок.
- 01Опиши цикл tool use. Кто вызывающий, кто вызываемый и что делает каждую итерацию дорогой?
- 02Зачем валидировать аргументы tool call, и что значит «валидировать» для мутирующего эндпоинта вроде cancel_order?
- 03Почему незащищённый цикл tool use — это и риск корректности, и риск стоимости, и какие два guard ты добавляешь?
- 04Когда модель может распараллелить tool call, а когда цепочка по своей сути последовательна?
- 05Объясни четыре настройки tool_choice и когда senior тянется к каждой.
- 06Откуда на самом деле берётся токеновая стоимость tools и каково стандартное смягчение?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: модель — вызывающий, а твой код — вызываемый, так что каждый round-trip это свежий, заново шлющий transcript вызов модели; аргументы — недоверенный вход, который ты валидируешь по схеме, затем authorize и existence-check, возвращая ошибки как tool_result; незащищённый цикл уходит в разнос, так что ограничь итерации и лови повторы; параллелизм помогает лишь независимым вызовам; tool_choice (auto/any/tool/none) задаёт, сработает ли tool и какой; а заново шлющийся массив tools — та токеновая стоимость, ради которой и существует prompt caching.