Когда ИИ-агенты и боты не нужны

Каждый инструмент решает свою задачу. ИИ-агенты — очень мощный и гибкий инструмент, но есть кейсы, когда мы отказались от их использования.

У нас есть запросы от пользователей, которые приходят через команду Customer Success. Не все запросы одинаково важны: есть действительно критические кейсы, есть просто важные запросы, есть что-то мелкое, а есть вообще просто непонимание со стороны пользователя. Для первых двух случаев обычно требуется оперативное вмешательство команды разработки.

Мы написали ИИ-агента в формате OpenAI Assistant, который мониторит канал в Slack и занимается первичной классификацией запросов. ИИ-агент знает все предыдущие переписки и легко находит схожие кейсы, предлагая уже существующее решение. Для новых кейсов ИИ-агент дозадаёт вопросы и заводит багу в JIRA. Затем тэгает нужную команду разработки.

И всё вроде хорошо, НО в таком формате отсутствует hard gate по заведению проблемы. То есть, например, CS написал о проблеме, бот дал совет, потом доспросил, и всё-таки выяснили, что это новая бага, и бот завёл её в JIRA. Время, пока бот доспрашивал и прояснял, а CS отвечал, могло затянуться на 2-3 дня.

И если проблема была важная — то потеряно время на её решение. Поэтому для важных проблем мы перешли на hard gate: жёсткая web-форма, которую нужно заполнить всю сразу, и мяч будет на стороне разработки только с момента сабмита формы.

Короче, процессы, где есть жёсткая передача ответственности по проблеме, лучше делать на hard gate (формах), а не на ботах, где есть мягкое длительное общение.

Подпишись 👉🏻 @aigentto 🤖

Хорошая подборка MCP серверов

Полезные для кодинга в Cursor/Anthropic MCP сервера. Так же можно применять и для своих систем Agentic AI.
👉 https://github.com/punkpeye/awesome-mcp-servers
👉 https://github.com/modelcontextprotocol/servers

💬 telegram-bot-mcp
🔧 Категория: Communication
Кейс: агент получает сообщение от пользователя с задачей ("подскажи, как это починить") → распознаёт intent → отвечает или делегирует другому агенту.
📌 Полезно для: запуска цепочек из Telegram, двустороннего общения, получения задач от реальных людей.

📚 wikipedia-mcp
🔧 Категория: Knowledge
Кейс: агент-помощник по обучению или ассистент для доклада автоматически ищет и вставляет пояснения или определения из Wikipedia.
📌 Полезно для: автоответов, генерации контекста, справки по терминам.

📊 notion-mcp
🔧 Категория: Notes & Docs
Кейс: агент-планировщик проекта добавляет задачи в Notion после обсуждения в Slack или анализа документа.
📌 Полезно для: ведения документации, действий после обсуждений, напоминаний и отчетов.

☁️ github-mcp
🔧 Категория: Developer Tools
Кейс: DevOps-агент обнаруживает баг в тестах, создаёт issue, затем другой агент комментирует и предлагает PR.
📌 Полезно для: автогенерации issue, отслеживания багов, CI/CD по запросу от LLM.

📅 google-calendar-mcp
🔧 Категория: Events & Calendars
Кейс: агент-секретарь анализирует переписку, предлагает время встречи, и сразу бронирует слот в календаре.
📌 Полезно для: интеграции с реальным расписанием, агент-планировщик.

🌍 serpapi-mcp
🔧 Категория: Internet APIs
Кейс: агент-журналист собирает свежую информацию по теме (например, новости, статистику) через Google Search API.
📌 Полезно для: агентов-исследователей, real-time актуализация информации.

📈 prometheus-mcp
🔧 Категория: Monitoring
Кейс: агент-монитор следит за нагрузкой на сервис, и если CPU > 80% → вызывает алерт-агента в Telegram.
📌 Полезно для: автономного мониторинга, оповещений, self-healing-сценариев.

📮 rabbitmq-mcp
🔧 Категория: Messaging Queues
Кейс: один агент планирует задачи, другой выполняет — они обмениваются сообщениями через очередь.
📌 Полезно для: построения очередей заданий между агентами, масштабирования.

🧠 replicate-mcp
🔧 Категория: ML & AI
Кейс: агент вызывает внешнюю модель — например, генерацию изображения, голоса или сегментацию.
📌 Полезно для: мультимодальных агентов, генеративных задач (text-to-image/audio).

Подпишись 👉🏻 @aigentto 🤖

Вектризовать SQL бессмыслено

При создании RAG обычно используются статические данные, которые по сути являются просто текстом.

Следующим этапом обычно хочется создать бота, который будет отвечать не только на основании инструкций и документов компании, но и сможет строить аналитику по реальным боевым данным компании. На этом этапе многие берут SQL-данные и пытаются превратить их в статические текстовые данные (векторизовать). Это не будет работать, потому что нам нужны живые данные из SQL: там большой объем информации, много числовых данных, а не текста, а с числами семантические подходы работают плохо.

В такой ситуации необходимо реализовать MCP-сервер для SQL, который будет получать запрос от бота, использовать LLM для определения того, какие данные (таблицы) нужны. Если в базе данных много таблиц, потребуется отправлять LLM всю схему, поэтому здесь выгодно использовать, например, что-то вроде OpenAI Assistant с system prompt (для экономии токенов).

После того как LLM определит необходимые таблицы, мы запускаем SQL-запросы, собираем результаты и, например, используем pandas для аналитических выводов. Только эти выводы (результаты анализа) отправляются в LLM, чтобы она сформулировала итоговый ответ.

Дополнительно рекомендуется использовать MV (Materialized View), чтобы не перегружать базу данных запросами.

Таким образом, LLM здесь нужна только для понимания запроса пользователя, поиска таблиц с нужными данными и составления человеческого ответа на основании уже обработанных данных.

Подпишись 👉🏻 @aigentto 🤖

Chain-of-thought промт для усиления целевого результата одним промтом

В одной RAG-системе есть довольно строгий промт и контекст. LLM отвечает, но иногда добавляет отсебятину, пытаясь быть полезной.
Инструкции в начале промта и даже в system prompt не всегда помогают.
Можно результат ещё раз валидировать через LLM или поиском лишних фраз в коде, но это требует дополнительного времени и токенов.

Чтобы получить всё по результатам первого запроса, можно добавить chain-of-thought промт — по сути, в конце, уже после промта и контекста, написать: «проанализируй свой ответ и проверь, что...».

Подпишись 👉🏻 @aigentto 🤖

Файлы Термины.txt и КтоЕстьКто.txt

При внедрении RAG очень часто выясняется, что система не может отвечать на запросы с неформальными терминами. Причина проста: в официальных документах этих терминов нет, но они в ходу у сотрудников компании. То же самое касается должностей сотрудников компании: в документах может быть Иван Иваныч Иванов с должностью "руководитель по обеспечению материальными средствами", но сотрудники его ищут по "завхоз".

Выход прост: сразу создавайте два файла в хранилище, откуда RAG будет брать свои знания для векторизации. Файл Термины.txt — пишите сюда все неформальные термины, которые в ходу, и КтоЕстьКто.txt (или Сотрудники.txt) — пишите сюда все неформальные названия должностей сотрудников.

Формат файлов, конечно, лучше делать сразу в markdown — тогда вы минимизируете проблемы с пониманием ваших файлов со стороны LLM.

Подпишись 👉🏻 @aigentto 🤖

Как тестировать качество ответов RAG/ИИ-агентов?

❗️Важно в начале при постановке задачи чётко определить, на какие вопросы система должна отвечать. В этом месте проваливается 50% внедрений, потому что обычно это выглядит так: надо, чтобы бот отвечал на вопросы по теме X, а потом ещё и по теме Y и т.д.

🚂 Составление конкретного списка вопросов и ожидаемых ответов заставляет раскрутить всю цепочку пайплайна бота:
👉 Но что он должен отвечать? Отвечать правду и по сути
👉 Где у нас источник этой правды? В документах
👉 Где эти документы? В каком они формате? Сколько их и про что они?

Самый простой вариант — это когда владельцы документов вручную берут и делают по два вопроса на каждый документ:
➕ Позитивный вопрос — ответ на который есть в конкретном документе.
➖ Негативный вопрос — вопрос по теме конкретного документа, ответа на который нет ни в этом документе, ни в других.

Дальше список вопросов автоматически (минуя цепочку бот→backend) можно прогонять при любых изменениях настроек llm, промта, контекста и делать скоринг:
+1 балл — ответил на вопрос,
0 баллов — не ответил на вопрос,
-1 балл — ответил на вопрос, но сказал неправду (галлюцинации).

И по каждой версии получаем общий score, который определяет её качество.

Для автогенерации таких вопросов и ответов мы уже сделали Python-код, надеюсь, скоро выложим в opensource.

Подпишись 👉🏻 @aigentto 🤖

Риски RAG/ИИ-агентов

Самый банальный риск ИИ-агентов — это prompt injections.

Какие бы вы данные ни собирали как контекст, какой бы промт ни строили, простая инструкция в конце промта может сильно исказить результат ответа в ту или иную сторону.

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

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

Плюс нужны security-гейты для валидации промтов, гейты на контекст, включая картинки, и гейты на проверку соответствия ответов llm запросу.

Подпишись 👉🏻 @aigentto 🤖

ИИ боты для замены покупателя

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

К примеру, я вчера 2 часа потратил на бронирование перелётов на всю семью (и везде я смотрел доступность, вбивал одни и те же данные). Хорошо бы это полностью поручить боту. Он про меня всё знает (личные данные и предпочтения) и готов выполнять задания по покупкам.

Одна проблема — это рынок B2C, и здесь не ясно, кто за это и сколько будет платить. Скорее всего, все захотят такого бота бесплатно, тогда он будет вынужден монетизироваться через рекламу, то есть он станет аффилированным с конкретными поставщиками товаров. Либо покупай premium-версию, и бот будет на твоей стороне 😎

Подпишись 👉🏻 @aigentto 🤖

Вышла статья про ChunkTester, будущий мегатул для правильной нарезки документов для RAG 😀

Подпишись 👉🏻 @aigentto 🤖

Мягкие и жесткие гейты валидации LLM

В рамках RAG или ИИ-агентов часто возникает вопрос — а как понять, что LLM вернула правильный ответ?

Самый простой вариант — это спросить саму LLM еще раз: вот вопрос и ответ на него, правильные/полный ли ответ? Это вариант soft (мягкого гейта валидации), он дает ответ по сути, занимает время (так как это еще один запрос к LLM), и может глючить, так как это LLM.

Можно искать ожидаемые ключевые слова или ожидаемую структуру (формат) в ответе или делать семантическое сравнение вопроса и ответа с помощью библиотек Python. Это будет hard (жесткий гейт валидации). Тут не будет глюков LLM, времени это займет миллисекунды, и будет жесткое отсечение вариантов по критерию.

Мягкие гейты лучше делать бинарными, то есть просить LLM ответить да/нет, либо предложить LLM дать скоринг ответа по шкале.

Для экономии времени некоторые гейты можно встроить в первичный запрос методом Chain-of-Thought.

Подпишись 👉🏻 @aigentto 🤖

Если агенты заходят в тупик (цикл)

Бывает, что агент или даже мультиагентная система заходит в тупик или в цикл. Самая яркая демонстрация — это IDE с LLM, где даже при детальной настройке инструкций некоторая задача может заставить агента/агентов править код туда/сюда, пытаясь прийти к желаемому результату.
Еще проще пример — это дать ChatGPT задачу на программирование, у которой нет решения (или нет очевидного решения).

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

Вот пример такого случая, когда LLM сдаётся 😀

И даже несмотря на то, что агенты и LLM-ки научились детектировать своё зацикленное поведение, они не способны решить эту проблему, хотя решение бывает очень простым с точки зрения человека-специалиста в теме.

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

Именно поэтому они сразу выглядят как неавтономные — человек, даже самый неумный, в цикл одинаковых задач не войдёт.

Суть проста — если LLM (или агенты вокруг LLM) вызывают последовательно одни и те же запросы с одним и тем же контекстом, попадание в такой цикл — вопрос лишь времени. То есть надо менять промты или контекст, или последовательность вызова агентов.

Решение — нужно иметь либoл мета-инструкцию (мета-агента), которому передается управление в этом случае и который способен перезапустить цепочку агентов-исполнителей с модифицированными промтами (заранее подготовленными), либо изменить последовательность запуска агентов (разорвать цепочку). Либо он запускает других агентов, сделанных специально для целей разруливания таких циклов.

Ещё один более крутой способ — это динамическая модификация промта внутри тех же агентов; помочь может даже модификация слов без изменения смысла. Это можно сделать с помощью той же LLM: сжать смысл, расширить смысл, уточнить смысл уже существующего промта.

Либо пойти ещё дальше и использовать эволюционные подходы (отбор сильнейших по fitness-функции и мутации) в модификации промтов или самого поколения агентов. Это будет уже очень близко к AGI, но потребует большого количества ресурсов, поэтому пока это скорее научное исследование (которое надеюсь мы сделаем), а не реально применимый способ.

Подпишись 👉🏻 @aigentto 🤖

Завышенные ожидания от LLM и магия ИИ-агентов

Довольно типичное ожидание от нейросетей и конкретно от ИИ-агентов:
📖 Даем много данных на вход
✨ Тут происходит магия
🏆 Получаем то, что мы хотим
🧠 То, что мы хотим, LLM сама поймет лучше нас

Как надо на самом деле:
👉 Даем достаточный минимум данных на вход (этот минимум надо определить экспериментально)
👉 Имеем четкие ожидания в виде: на вход X, на выходе Y

Очень часто описания "вход-выход" не определены, вопросы и ожидаемый результат не определены.

Описания должны быть в форме "пример входных данных -> пример ожидаемого результата".

Теоретическое описание типа "на вход даем схему гиперболоида и методологию сборки антивещества, а на выходе он собирает автомобиль Москвич" не является корректным примером "вход vs. выход".

Подпишись 👉🏻 @aigentto 🤖

LLM не знаем какой сейчас год

Проблема банальная, но частая. LLM модели тренированы на какой-то момент, и для некоторых моделей (например, mini) это может быть 2023 год. В результате модель на вопросы типа «сколько лет прошло с ...» и подобные будет отвечать неправильно.

Решение простое — в system prompt всегда передавать:

f"Имей ввиду сегодня {today}."

где today:

today = datetime.now().strftime("%-d %B %Y")

Подпишись 👉🏻 @aigentto 🤖

Факт чекинг RAG системы

RAG берет данные из векторной БД, куда данные попадают в виде чанков (векторов) из ваших документов. Затем есть важный параметр top-k, который определяет, сколько чанков получать при запросе пользователя, то есть будут получены X чанков, наиболее семантически схожих с запросом пользователя. В этом вся магия векторного представления.

Дальше разные настройки LLM (температура и top-k) могут сильно влиять на то, как LLM интерпретирует полученные чанки, и даже если поставить temperature=0, то LLM может изобрести что-то новое (что по факту неправда) из набора чанков.

Для полного избегания этого можно использовать гейт факт-чекинга: после получения ответа от LLM все выбранные чанки, откуда была получена информация и ответ LLM, передаются обратно в нейросеть с вопросом: "найди чанк, из которого получена информация в ответе, используй строгое соответствие, не предлагаю чанки, в которых есть похожая информация". Если чанк не найден или найдено много чанков, то высока вероятность провала гейта факт-чекинга.

Подпишись 👉🏻 @aigentto 🤖

Адаптивный порог выборки top-k векторов

Часто бывает сложно определить, какой top-k нужно выбирать для качественного ответа RAG. Если выбрать мало — не сможет ответить, если много — начнет сочинять.
Плюс этот параметр часто нужно менять после существенного изменения количества и типа документов, на основе которых отвечает RAG.

Но есть способ сделать этот параметр адаптивным. Для начала нужно иметь автооценку ответов. Гейт автооценки можно организовать, как описано тут. После этого, если у нас становится больше score = 0, нужно увеличить top-k. Если стало много score = -1, нужно уменьшить top-k.

Подпишись 👉🏻 @aigentto 🤖

Неполный вопрос от пользователя

Бывает, ленится не LLM, а пользователь системы, и задаёт вопросы, из которых сложно понять, что он спрашивает.

Например: "Хочу поиграть в футбол?" вместо "Где в компании можно поиграть в футбол?". Первый вариант может быть воспринят LLM как просто выражение своего желания, не связанного с тем, что есть в компании, и вместо ответа пользователь получит "Хорошая идея!" 😀

Для исключения недопонимания можно добавить гейт прояснения вопроса. Надо отправить вопрос в LLM и спросить: "В этом сообщении есть вопрос от пользователя или нет? Отвечай да или нет".

Если ответ — нет, то просим LLM прояснить, что хочет пользователь. Это можно сделать и в одном промте по схеме chain-of-thought: "В этом сообщении есть вопрос от пользователя или нет? Если вопроса нет, то задай дополнительный вопрос, проясняющий, что хочет пользователь, если вопрос уже есть — ответь да".

Подпишись 👉🏻 @aigentto 🤖

Динамические промты

Обычно промты для RAG и ИИ-агентов подбираются вручную и фиксируются, пока не обнаруживается новая проблема. После её обнаружения промт апдейтится. Это очень надёжный подход, хорошо себя зарекомендовавший.

Но никто не мешает сделать промты RAG и ИИ-агентов динамическими. Для этого нужно иметь гейт валидации ответа. Если гейт даёт красный сигнал, то проблема может быть в том числе и в промте. После этого мы просим LLM внимательно рассмотреть промт и внести изменения, чтобы улучшить ответ на текущий запрос.

Это не всегда сработает, потому что проблема может быть не в промте. Если не сработало, то промт не меняем, если сработало — новый промт становится новой нормой для конкретного ИИ-агента или RAG-системы. Важно следить, чтобы изменение не было кардинальным, чтобы не поломать другие случаи.

Подпишись 👉🏻 @aigentto 🤖