Что такое tool-use
Tool-use — это режим, в котором LLM не просто генерирует текст, а умеет вызывать внешние инструменты: поиск по базе знаний, запрос в 1С или CRM, веб-поиск, создание задачи, отправку письма, проверку статуса заказа или расчёт по формуле.
По сути, модель перестаёт быть «умным чатиком» и становится оркестратором. Она видит задачу, решает, какой инструмент нужен, вызывает его и уже потом собирает ответ.
Именно в этом и состоит разница между обычным чатом и агентом: агент не обязан угадывать всё из головы.
Почему это важно для бизнеса
У многих компаний есть одна и та же боль: в системе уже лежат нужные данные, но человек всё равно тратит время на поиск, сведение, перепроверку и ручные переходы между окнами.
Tool-use убирает этот разрыв.
- Сотрудник задаёт вопрос один раз.
- Агент сам решает, где искать ответ.
- Если данных не хватает, он делает ещё один запрос.
- Если нужен формальный ответ, он поднимает его из источника, а не сочиняет.
Это особенно полезно там, где есть документы, ERP, CRM, service desk, база знаний, портал сотрудников и много повторяющихся запросов.
Агент не должен просто «болтать»
Хороший агент не обязан отвечать сразу. Иногда лучший ответ — это ещё один поиск.
Именно поэтому мы в AI Platforms смотрим на tool-use не как на украшение, а как на рабочий механизм управления неопределённостью. Если модель не уверена, она должна уметь:
- вызвать поиск по документам;
- проверить другой источник;
- запросить уточнение у пользователя;
- вернуть не фантазию, а честное «мне нужно ещё одно подтверждение».
Это и есть зрелый сценарий, а не демо с красивой цепочкой действий.
Откуда выросла эта идея
Современный tool-use не возник на пустом месте.
Исследование "ReAct" показало, что модели лучше справляются с задачами, когда рассуждение и действие идут вместе: сначала модель думает, потом делает действие, потом снова думает на основе результата.
Потом "Toolformer" показал, что языковая модель может сама научиться вызывать инструменты через API и выбирать, когда это действительно нужно.
А подходы вроде "Self-RAG" пошли ещё дальше: модель не просто ищет один раз, а адаптивно решает, когда ей нужно ещё retrieval, когда достаточно найденного, и когда нужно критически оценить собственный ответ.
Если перевести это на бизнес-язык, идея простая: агент должен не просто генерировать ответ, а уметь добирать недостающий контекст.
Где tool-use особенно полезен
Есть несколько сценариев, где агенты с инструментами реально дают эффект.
- Сервис-деск: классификация заявки, поиск по базе знаний, черновик ответа, эскалация.
- Продажи: подбор решения по параметрам клиента, проверка остатков, расчёт следующего шага.
- Закупки: поиск по каталогу, сравнение поставщиков, сборка сводки.
- HR: регламенты, типовые справки, заявки и внутренние процедуры.
- Операции: проверка статусов, уведомления, контроль событий, поиск причин инцидента.
- Документы: поиск по файловому хранилищу, краткий вывод, ссылки на первоисточник.
Во всех этих случаях агент ценен не потому, что он «говорит умнее», а потому, что он сокращает количество ручных переходов между системами.
Наш подход к RAG через tools
Здесь как раз начинается наша основная фишка.
Мы не считаем правильным просто пихать большие куски RAG в контекст и надеяться, что модель сама разберётся.
Вместо этого мы строим RAG как инструмент, которым агент может пользоваться по мере необходимости.
Это выглядит так:
1. Пользователь задаёт вопрос.
2. Агент сначала пытается понять, хватает ли ему уже имеющихся данных.
3. Если нет, он вызывает поиск по базе знаний или документам.
4. Если результат слабый, он делает следующий поисковый шаг или уточняет запрос.
5. Если данных всё ещё недостаточно, он честно говорит об этом и предлагает следующий шаг.
Такой подход лучше, чем один большой неподвижный контекст, потому что:
- модель не перегружается лишними фрагментами;
- поиск можно делать итеративно;
- можно отрабатывать неопределённость;
- можно включать доступы и ограничения на уровне инструментов;
- можно проверить, почему агент пришёл именно к этому выводу.
Если нужен базовый контекст про сам RAG, см. нашу статью RAG для бизнеса: зачем он нужен и чем он отличается от большого контекста.
Что происходит, если инструментов слишком много
Tool-use быстро становится вредным, если не поставить рамки.
Обычные ошибки такие:
- агенту дают слишком широкий доступ к системам;
- нет разделения прав между пользователями;
- инструменты вызываются без ограничений по стоимости и времени;
- нет журнала действий;
- непонятно, какой источник был использован для ответа;
- агент входит в бесконечный цикл поиска и уточнений.
Поэтому хорошая агентная архитектура всегда включает:
- ограниченный набор инструментов;
- права доступа на уровне ролей;
- тайм-ауты и лимиты;
- журналирование действий;
- остановку по confidence threshold или по количеству шагов;
- fallback на человека, когда уверенности недостаточно.
Где tool-use ломается в безопасности
Чем больше у агента инструментов, тем важнее безопасность.
Если агент читает документы, письма, веб-страницы или пользовательский ввод, в контекст может попасть вредоносная инструкция. Именно поэтому prompt injection остаётся актуальной угрозой и для RAG, и для агентных систем.
Отсюда простой вывод: агент не должен доверять всему, что он прочитал.
Нужны фильтры источников, нормализация входа, политика доверия к данным и чёткое разделение между инструкциями и содержимым документа.
Как понять, что агент работает хорошо
Полезный агент измеряется не количеством «шагов мышления», а качеством результата.
Смотрим обычно на следующее:
- сколько запросов он закрывает без человека;
- как часто он ошибается в источнике;
- как часто делает лишние вызовы инструментов;
- сколько времени занимает ответ;
- где он должен был остановиться и позвать оператора;
- сколько шума он добавляет в рабочий процесс.
Если агент ускоряет работу и не создаёт хаоса, он полезен. Если он делает красивую демо-автоматизацию, но ломает контроль и поддержку, это ещё не production.
Где мы видим реальную ценность
На практике tool-use лучше всего работает там, где есть повторяющиеся действия и много внутренних источников данных.
Это могут быть:
- корпоративные ассистенты;
- support-боты;
- внутренние помощники для продаж и закупок;
- ассистенты для производственных и сервисных команд;
- hybrid RAG-сценарии, где нужно искать, уточнять и возвращать ссылку на источник.
Именно в таких задачах агент перестаёт быть игрушкой и становится частью операционного контура.
Итог
Tool-use делает LLM полезнее не потому, что добавляет «магии», а потому, что учит её работать с реальностью: искать, проверять, уточнять и останавливаться, если данных недостаточно.
Для нас это особенно важно в RAG-сценариях. Мы считаем, что лучший корпоративный поиск — это не статичный кусок текста в контексте, а система, которая умеет сама добирать информацию через инструменты и возвращать честный ответ.
Если хотите, мы можем помочь спроектировать agentic RAG: от поиска по базе знаний до интеграции с 1С, CRM, документами и внутренними сервисами.