Что такое инструмент и зачем он языковой модели

Зачем это знать

• Понять, откуда система берёт свежие данные и кто отвечает за неверное действие
• Отличать сборку, которая умеет делать, от сборки, которая умеет только рассказывать
• Спрашивать подрядчика список инструментов и права доступа к каждому

Что такое инструмент простыми словами

Оператор справочной службы держит в голове правила. Условия договора, сроки, порядок возврата — это память. А остаток по счёту он смотрит в программе: наизусть такое не запоминается и меняется каждый день.

Инструмент для языковой модели — тот самый доступ к программе. Модель обучена на текстах и знает общие правила. Что происходит в учётной системе прямо сейчас, она не знает.

Инструмент закрывает этот разрыв. Ему дают имя, короткое описание назначения и список полей, которые нужно заполнить: номер договора, период, сумма. Модель видит этот список так же, как оператор видит форму поиска на экране. Выполняет запрос программа, а вызов инструментов — та часть, где модель говорит, что именно ей нужно.

Как это работает

Ключевое место — третий шаг. Модель ничего не выполняет, она только просит. Всё, что происходит дальше, делает обычный код по обычным правилам доступа.

Отсюда следует практическая вещь. Права на инструмент выдаются не модели, а роли сотрудника, от чьего имени идёт запрос. Менеджер видит свои сделки, бухгалтер — свои документы. Модель не расширяет ничьи полномочия.

Описания инструментов лежат во входном объёме каждого запроса. Десять подробных описаний прибавляют к счёту столько же, сколько небольшой документ, — считается это в токенах. Поэтому список держат коротким и переписывают описания сжато.

Число шагов в одном обращении ограничивают заранее. Без ограничения модель способна ходить по кругу: запросила, не поняла, запросила снова. Лимит в три-пять вызовов на обращение снимает эту статью расходов и заодно держит время ответа.

Отказ инструмента обрабатывается отдельно. Система недоступна, договор не найден, поле заполнено неверно — на каждый случай пишется, что модель говорит человеку. Без этого приходит связный ответ, собранный из ничего, — та самая галлюцинация, только дороже.

Пример из практики

«Не пришёл счёт за март» — это три разных обращения. Счёт не сформирован. Счёт ушёл на старый адрес. Счёт пришёл, но не открывается.

Текстом на все три отвечают одинаково и бесполезно. С инструментами разбор идёт по шагам: найти счёт по номеру договора, посмотреть статус отправки, проверить адрес в карточке. Три коротких запроса вместо одного длинного письма клиенту.

Дальше решают, где проходит граница. Найти и показать — можно всем. Выслать повторно — можно. Изменить адрес рассылки или пересчитать сумму — только через подтверждение человека, потому что цена ошибки выходит за пределы одного диалога.

Результат такой сборки замеряют долей обращений, закрытых без оператора. Берут один и тот же поток за две-четыре недели, до и после. Прикинуть, во что обходится тот же разбор руками, помогает калькулятор стоимости ручного процесса.

Что это даёт бизнесу

• Ответ опирается на данные, а не на память модели. Статус заказа, остаток, срок доставки берутся из системы в момент вопроса. Спорить с таким ответом нечем: рядом лежит запись, откуда он взялся.
• Появляется журнал. Каждый вызов пишется: кто спросил, какой инструмент дёрнули, с какими полями, что вернулось. Разбор жалобы занимает минуты и не требует восстанавливать разговор по памяти.
• Работа делится на дешёвую и дорогую. Часть шагов закрывается прямой интеграцией без модели вовсе — там, где условие жёсткое и записано. Модели остаётся разбор формулировок и выбор ветки. Оценить, какие участки процесса готовы к этому, помогает чек-лист готовности.
• Риск ограничивается списком. Модель может ровно то, что перечислено. Не подключён инструмент — действие невозможно физически, а не по договорённости.

Когда без этого можно обойтись

Инструменты не нужны там, где ответ целиком лежит в тексте. Черновики писем, переводы, сводки по приложенному документу, разбор одного файла — модель справляется без выходов наружу.

Не нужны они и когда данные меняются редко. Прайс на квартал, регламент, инструкция — это база знаний, её дешевле подключить поиском по документам.

Третий случай — единичный объём. Несколько запросов в день закрываются человеком за минуту, а подключение, права и журнал стоят как отдельный проект.

Что важно проверить

Первое: попросите список инструментов с правами. На каждый — от чьего имени идёт запрос, какие поля, что происходит при отказе системы. Список из трёх строк лучше обещания «подключим всё нужное».

Второе: разделите чтение и запись. Читающие инструменты запускают сразу, пишущие — после того, как на потоке видно, что модель выбирает верно. Действия с деньгами и внешними отправками остаются за подтверждением человека даже потом.

Третье: проверьте, что происходит при неверном выборе. Хорошая сборка отвечает «данные не найдены» и передаёт человеку. Плохая — придумывает правдоподобный ответ, и заметно это только на жалобе клиента.