Тонкая настройка работы RAG-системы
Когда уже всё работает и система отвечает хорошо, но бывают кейсы галлюцинаций LLM, необходимо заняться тонкой настройкой выборки чанков.
🐳 Нужно поиграть с размером и overlap (взаимным перекрытием чанков)
🔪 Если не помогает, нужно изменить нарезку чанков: вместо отрезания по чёткой длине (300, 1000, 2000 символов) можно начать резать, учитывая целые слова и предложения
📦 В выборке нужно поиграть с количеством выбранных чанков — лишняя информация часто заставляет галлюцинировать LLM
💀 Нужно сравнить общий объём контекста, который вы даёте LLM, и размер промта. Если размер контекста значительно больше самого промта, и в документах появляются фразы семантически схожие с тем, какие вы инструкции даёте, то LLM начнёт игнорировать ваши инструкции и принимать контекст за указание к действию
Всё это занимает много времени в цикле:
👉 поменял
👉 переиндексировал векторную БД
👉 прогнал тестовые вопросы
👉 повтор
Лучше делать изменения понемногу, иначе качество ответов может сильно поменяться, без понимания причины.
Я называю это ЧАНКИНГ 😁
Подпишись 👉🏻 @aigentto 🤖
Когда уже всё работает и система отвечает хорошо, но бывают кейсы галлюцинаций LLM, необходимо заняться тонкой настройкой выборки чанков.
🐳 Нужно поиграть с размером и overlap (взаимным перекрытием чанков)
🔪 Если не помогает, нужно изменить нарезку чанков: вместо отрезания по чёткой длине (300, 1000, 2000 символов) можно начать резать, учитывая целые слова и предложения
📦 В выборке нужно поиграть с количеством выбранных чанков — лишняя информация часто заставляет галлюцинировать LLM
💀 Нужно сравнить общий объём контекста, который вы даёте LLM, и размер промта. Если размер контекста значительно больше самого промта, и в документах появляются фразы семантически схожие с тем, какие вы инструкции даёте, то LLM начнёт игнорировать ваши инструкции и принимать контекст за указание к действию
Всё это занимает много времени в цикле:
👉 поменял
👉 переиндексировал векторную БД
👉 прогнал тестовые вопросы
👉 повтор
Лучше делать изменения понемногу, иначе качество ответов может сильно поменяться, без понимания причины.
Я называю это ЧАНКИНГ 😁
Подпишись 👉🏻 @aigentto 🤖
👍5
Жесткие критерии тестирования RAG-систем или почему вопросы имеют значение?
Так как LLM — очень гибкий инструмент, при создании RAG-систем и ИИ-агентов всегда будут кейсы, когда оно отвечает/понимает немного по-разному. Особенно это касается сложных запросов, где много предположений и недосказанностей.
Поэтому список вопросов для тестирования LLM должен быть четким, и все вопросы должны быть развернутыми.
Пример плохих вопросов:
- кто у нас зам згд
- дай контакты делле
- кто у нас самый главный
LLM, конечно, попробует догадаться, что «згд» в нашем контексте — возможно заместитель генерального директора... а «самый главный» — это, наверное, генеральный или председатель? А «делле» — это, наверное, фамилия?
Но, во-первых, может и не догадаться, а во-вторых, если догадается, то, учитывая сложную семантику, оно может начать догадываться дальше, и в ответ попадут неточные или совсем неверные данные.
❕Нужно помнить, что всё, что делает LLM — это догадывается, какой следующий токен. Поэтому чем точнее заданное направление, тем точнее ответ и меньше галлюцинаций.
👉 Либо задавайте развернутые вопросы, на которые точно есть ответ в документах.
💡 Либо вносите в свои документы свои же термины. По сути, можно просто добавить к документам файл термины.txt и там разжевывать все места, где модель глючит. Таким образом можно не переделывать оригинальные доки.
Подпишись 👉🏻 @aigentto 🤖
Так как LLM — очень гибкий инструмент, при создании RAG-систем и ИИ-агентов всегда будут кейсы, когда оно отвечает/понимает немного по-разному. Особенно это касается сложных запросов, где много предположений и недосказанностей.
Поэтому список вопросов для тестирования LLM должен быть четким, и все вопросы должны быть развернутыми.
Пример плохих вопросов:
- кто у нас зам згд
- дай контакты делле
- кто у нас самый главный
LLM, конечно, попробует догадаться, что «згд» в нашем контексте — возможно заместитель генерального директора... а «самый главный» — это, наверное, генеральный или председатель? А «делле» — это, наверное, фамилия?
Но, во-первых, может и не догадаться, а во-вторых, если догадается, то, учитывая сложную семантику, оно может начать догадываться дальше, и в ответ попадут неточные или совсем неверные данные.
❕Нужно помнить, что всё, что делает LLM — это догадывается, какой следующий токен. Поэтому чем точнее заданное направление, тем точнее ответ и меньше галлюцинаций.
👉 Либо задавайте развернутые вопросы, на которые точно есть ответ в документах.
💡 Либо вносите в свои документы свои же термины. По сути, можно просто добавить к документам файл термины.txt и там разжевывать все места, где модель глючит. Таким образом можно не переделывать оригинальные доки.
Подпишись 👉🏻 @aigentto 🤖
❤7
ИИ-агенты для найма сотрудников
В технических вакансиях, таких как Software Developer, где можно провести предварительную оценку по тех. заданиям и коду на GitHub, LLM очень сильно экономит время на отбор тех, с кем надо поговорить.
У нас идет найм, и за 24 часа — 174 отклика. С помощью LLM уже всё разобрано и выбраны кандидаты для следующих этапов. Осталось только собрать всё это в ИИ-агента, который сам будет отвечать на hh.ru и назначать собесы, но, учитывая, что найм — это не постоянная история, тут ROI может быть отрицательным.
Хотя в других областях, где найм идет постоянно, — это может быть реально выгодно 💰
Подпишись 👉🏻 @aigentto 🤖
В технических вакансиях, таких как Software Developer, где можно провести предварительную оценку по тех. заданиям и коду на GitHub, LLM очень сильно экономит время на отбор тех, с кем надо поговорить.
У нас идет найм, и за 24 часа — 174 отклика. С помощью LLM уже всё разобрано и выбраны кандидаты для следующих этапов. Осталось только собрать всё это в ИИ-агента, который сам будет отвечать на hh.ru и назначать собесы, но, учитывая, что найм — это не постоянная история, тут ROI может быть отрицательным.
Хотя в других областях, где найм идет постоянно, — это может быть реально выгодно 💰
Подпишись 👉🏻 @aigentto 🤖
Chain-of-though или reasoning/thinking
В LLM давно появились режимы reasoning/thinking, но такую же штуку можно сделать и на любой старой модели или, например, на модели локальной.
Достаточно лишь попросить:
👉 Пошаговое объяснение - «Давай решим шаг за шагом», «Объясни ход мысли».
👉 Переформулировать задачу - «Расскажи своими словами, что нужно сделать».
👉 Разбить задачу на части - «На какие этапы можно разделить решение?».
👉 Проверить или предложить другой способ - «Проверь ответ», «Есть ли альтернативы?».
👉 Задай роль эксперта: «Ты — эксперт, рассуждающий логично и подробно».
Но и самое главное — это просто после каждого ответа доспрашивать: «А что ты думаешь по...?», «А какие еще есть варианты?» и даже тупое «а если еще подумать?» включит режим "thinking".
По сути, никакого режима reasoning/thinking в LLM моделях нет, это просто метод, где ты её гоняешь по циклу — дозадавая вопросы, пока уровень ответа не будет достаточно точным.
Это круто работает и в RAG. Вместо одного запроса с контекстом можно задать один и тот же запрос несколько раз, докручивая результат.
Подпишись 👉🏻 @aigentto 🤖
В LLM давно появились режимы reasoning/thinking, но такую же штуку можно сделать и на любой старой модели или, например, на модели локальной.
Достаточно лишь попросить:
👉 Пошаговое объяснение - «Давай решим шаг за шагом», «Объясни ход мысли».
👉 Переформулировать задачу - «Расскажи своими словами, что нужно сделать».
👉 Разбить задачу на части - «На какие этапы можно разделить решение?».
👉 Проверить или предложить другой способ - «Проверь ответ», «Есть ли альтернативы?».
👉 Задай роль эксперта: «Ты — эксперт, рассуждающий логично и подробно».
Но и самое главное — это просто после каждого ответа доспрашивать: «А что ты думаешь по...?», «А какие еще есть варианты?» и даже тупое «а если еще подумать?» включит режим "thinking".
По сути, никакого режима reasoning/thinking в LLM моделях нет, это просто метод, где ты её гоняешь по циклу — дозадавая вопросы, пока уровень ответа не будет достаточно точным.
Это круто работает и в RAG. Вместо одного запроса с контекстом можно задать один и тот же запрос несколько раз, докручивая результат.
Подпишись 👉🏻 @aigentto 🤖
Новый обязательный вопрос на интервью разработчиков
Сейчас ведём найм backend-разработчиков, и на screening-интервью я добавил новый обязательный вопрос: А как вы используете LLM или IDE с LLM для написания кода?
Отвечать на такой вопрос — почти не использую, всё пишу сам — это примерно как отвечать 100 лет назад, что автомобиль пока не использую, лошадь надёжнее и понятнее.
LLM и всякие Cursor, Anthropic уже несколько лет с нами, вы просто обязаны их использовать для увеличения своей производительности 🚀
👉 Первый уровень — это обычно просто web-чат с ChatGPT по конкретному коду
👉 Второй уровень — это IDE с настройкой system prompt под свой проект (чтобы оно не тупило и не делало плохие штуки)
👉 Третий уровень — это подключение всяких JIRA, Wiki через MCP, чтобы бизнес-документация сама бралась в LLM, и задачки в JIRA сами двигались по workflow
Второй и третий уровень требуют усилий по настройке и тюнингу под ваши проекты, но если вы этого не сделаете, то и в XXI веке всё ещё будете использовать надёжную, хорошую, проверенную веками лошадь 🐴
Подпишись 👉🏻 @aigentto 🤖
Сейчас ведём найм backend-разработчиков, и на screening-интервью я добавил новый обязательный вопрос: А как вы используете LLM или IDE с LLM для написания кода?
Отвечать на такой вопрос — почти не использую, всё пишу сам — это примерно как отвечать 100 лет назад, что автомобиль пока не использую, лошадь надёжнее и понятнее.
LLM и всякие Cursor, Anthropic уже несколько лет с нами, вы просто обязаны их использовать для увеличения своей производительности 🚀
👉 Первый уровень — это обычно просто web-чат с ChatGPT по конкретному коду
👉 Второй уровень — это IDE с настройкой system prompt под свой проект (чтобы оно не тупило и не делало плохие штуки)
👉 Третий уровень — это подключение всяких JIRA, Wiki через MCP, чтобы бизнес-документация сама бралась в LLM, и задачки в JIRA сами двигались по workflow
Второй и третий уровень требуют усилий по настройке и тюнингу под ваши проекты, но если вы этого не сделаете, то и в XXI веке всё ещё будете использовать надёжную, хорошую, проверенную веками лошадь 🐴
Подпишись 👉🏻 @aigentto 🤖
🤔1
Как сделать чтобы RAG отвечал мгновенно
При большом кол-ве пользователей запрос на скорость ответа от RAG обычно растет. Хочется за 2-4 секунды получать ответ. Но можно сделать так, чтобы ~30-60% "отвечались" мгновенно.
Для этого достаточно прикрутить семантический кэш:
1️⃣ Все пары вопрос ответ переводим в пары эмбеддинга запроса + текст ответа
2️⃣ Каждый новый вопрос тоже переводим в вектор и по нему ищем совпадающие c определенной точность, например семантическое совпадение >= 0.89
Получаем мгновенный ответ. Чем больше у нас одинаковых по сути вопросов, тем чаще будет возвращаться значение из кэша.
Тут есть пример кода https://t.me/KodduuPython/1186
Подпишись 👉🏻 @aigentto 🤖
При большом кол-ве пользователей запрос на скорость ответа от RAG обычно растет. Хочется за 2-4 секунды получать ответ. Но можно сделать так, чтобы ~30-60% "отвечались" мгновенно.
Для этого достаточно прикрутить семантический кэш:
1️⃣ Все пары вопрос ответ переводим в пары эмбеддинга запроса + текст ответа
2️⃣ Каждый новый вопрос тоже переводим в вектор и по нему ищем совпадающие c определенной точность, например семантическое совпадение >= 0.89
Получаем мгновенный ответ. Чем больше у нас одинаковых по сути вопросов, тем чаще будет возвращаться значение из кэша.
Тут есть пример кода https://t.me/KodduuPython/1186
Подпишись 👉🏻 @aigentto 🤖
Telegram
Kodduu Python
🎯 Как встроить семантический кэш в RAG и перестать зря гонять LLM
Ускорь ответы, сократи расходы и добавь ум в своего ассистента! 💡
Вот реальный пример кода, который:
* 🔐 Сохраняет пары "вопрос — ответ"
* 🧠 Находит похожие вопросы через cosine similarity…
Ускорь ответы, сократи расходы и добавь ум в своего ассистента! 💡
Вот реальный пример кода, который:
* 🔐 Сохраняет пары "вопрос — ответ"
* 🧠 Находит похожие вопросы через cosine similarity…
🔥3
Как минимизировать галлюцинации в RAG?
У любой LLM две основные проблемы — laziness и hallucination. Обе проблемы тем вероятнее, чем больший размер промта вы передаете.
🪲 laziness (лень) — модель не ответила на все вопросы, которые были в промте
🐞 hallucination (галлюцинации) — модель уверенно соврала
Если задать один конкретный короткий вопрос, то проблем лени и галлюцинаций у LLM не будет, но если передать в модель 5–10 страниц текста, где есть длинный промт и много контекста, то вероятность обеих проблем сильно возрастает.
Надо понимать, что весь объем переданного текста в LLM для модели является просто набором токенов, и в случае RAG-систем, когда мы передаем много контекста и соотношение промта и контекста сильно смещается в сторону контекста, вес того, что сказано в контексте, может быть значительно больше, и модель проигнорирует некоторые правила, которые вы ей задали в самом промте.
Особенно это критично, если в самом контексте из чанков будут семантически похожие конструкции — они могут быть восприняты моделью как прямое указание к действию (это аналог prompt injection).
Для борьбы с этим можно:
👉 Передавать сам промт в конце, а не в начале
👉 Минимизировать размер контекста, делать выборку топ-5 вместо топ-10 чанков
👉 Делать размер чанков контекста меньше
👉 Чистить контекст на предмет семантических конструкций, схожих с промтом
👉 Добавить гейт валидации после ответа модели для проверки — ответила ли модель на все вопросы и нет ли там данных, которые отсутствуют в извлеченных чанках контекста
Подпишись 👉🏻 @aigentto 🤖
У любой LLM две основные проблемы — laziness и hallucination. Обе проблемы тем вероятнее, чем больший размер промта вы передаете.
🪲 laziness (лень) — модель не ответила на все вопросы, которые были в промте
🐞 hallucination (галлюцинации) — модель уверенно соврала
Если задать один конкретный короткий вопрос, то проблем лени и галлюцинаций у LLM не будет, но если передать в модель 5–10 страниц текста, где есть длинный промт и много контекста, то вероятность обеих проблем сильно возрастает.
Надо понимать, что весь объем переданного текста в LLM для модели является просто набором токенов, и в случае RAG-систем, когда мы передаем много контекста и соотношение промта и контекста сильно смещается в сторону контекста, вес того, что сказано в контексте, может быть значительно больше, и модель проигнорирует некоторые правила, которые вы ей задали в самом промте.
Особенно это критично, если в самом контексте из чанков будут семантически похожие конструкции — они могут быть восприняты моделью как прямое указание к действию (это аналог prompt injection).
Для борьбы с этим можно:
👉 Передавать сам промт в конце, а не в начале
👉 Минимизировать размер контекста, делать выборку топ-5 вместо топ-10 чанков
👉 Делать размер чанков контекста меньше
👉 Чистить контекст на предмет семантических конструкций, схожих с промтом
👉 Добавить гейт валидации после ответа модели для проверки — ответила ли модель на все вопросы и нет ли там данных, которые отсутствуют в извлеченных чанках контекста
Подпишись 👉🏻 @aigentto 🤖
👍1
Еще одна невероятная способность LLM 🔥
Есть очевидная, но достаточно мало используемая способность LLM — это возможность восстанавливать битый текст.
В нашем случае есть расчетный лист с очень плохим качеством в виде пиксельного PDF. Распознавая его в текст, мы получаем битый текст (70% может быть битым), но LLM все воспринимает как последовательность токенов, и имея даже 30% информации, она достаточно легко догадывается, что было в 70% битых процентах.
Если у вас есть задачи, где входящая информация не качественная, то использование LLM — самый лучший и надежный вариант для ее восстановления.
Древние рукописи с бересты можно восстановить🙂
Подпишись 👉🏻 @aigentto 🤖
Есть очевидная, но достаточно мало используемая способность LLM — это возможность восстанавливать битый текст.
В нашем случае есть расчетный лист с очень плохим качеством в виде пиксельного PDF. Распознавая его в текст, мы получаем битый текст (70% может быть битым), но LLM все воспринимает как последовательность токенов, и имея даже 30% информации, она достаточно легко догадывается, что было в 70% битых процентах.
Если у вас есть задачи, где входящая информация не качественная, то использование LLM — самый лучший и надежный вариант для ее восстановления.
Древние рукописи с бересты можно восстановить🙂
Подпишись 👉🏻 @aigentto 🤖
🔥7
Что такое CAG и как оно экономит время ответа и токены?
В обычной RAG системе flow такой:
1️⃣ Запрос пользователя
2️⃣ Поиск топ векторов по БД
3️⃣ Даем LLM на вход наш prompt
4️⃣ Набор найденных релевантных к вопросы векторов (чанков)
5️⃣ Получаем ответ модели
Для ускорения ответа и экономии токенов мы можем сохранять все пары вопрос-ответ и после шага 1️⃣ делать семантический поиск по парам вопрос-ответ. Все найденные схожие ответы-вопросы с текущим запросом мы отдаем LLM на вход как контекст, и она отвечает на основе предыдущих схожих ответов-вопросов.
То есть для существующих в кэше ответов не делаем запрос в БД и не отправляем большое количество чанков в LLM. Получаем экономию времени и токенов 🎉
Это и называется CAG: Cache-Augmented Generation. Вот пример https://github.com/ronantakizawa/cacheaugmentedgeneration
Подпишись 👉🏻 @aigentto 🤖
В обычной RAG системе flow такой:
1️⃣ Запрос пользователя
2️⃣ Поиск топ векторов по БД
3️⃣ Даем LLM на вход наш prompt
4️⃣ Набор найденных релевантных к вопросы векторов (чанков)
5️⃣ Получаем ответ модели
Для ускорения ответа и экономии токенов мы можем сохранять все пары вопрос-ответ и после шага 1️⃣ делать семантический поиск по парам вопрос-ответ. Все найденные схожие ответы-вопросы с текущим запросом мы отдаем LLM на вход как контекст, и она отвечает на основе предыдущих схожих ответов-вопросов.
То есть для существующих в кэше ответов не делаем запрос в БД и не отправляем большое количество чанков в LLM. Получаем экономию времени и токенов 🎉
Это и называется CAG: Cache-Augmented Generation. Вот пример https://github.com/ronantakizawa/cacheaugmentedgeneration
Подпишись 👉🏻 @aigentto 🤖
GitHub
GitHub - ronantakizawa/cacheaugmentedgeneration: A Demo of Cache-Augmented Generation (CAG) in an LLM
A Demo of Cache-Augmented Generation (CAG) in an LLM - ronantakizawa/cacheaugmentedgeneration
👍5
Когда ИИ-агенты и боты не нужны
Каждый инструмент решает свою задачу. ИИ-агенты — очень мощный и гибкий инструмент, но есть кейсы, когда мы отказались от их использования.
У нас есть запросы от пользователей, которые приходят через команду Customer Success. Не все запросы одинаково важны: есть действительно критические кейсы, есть просто важные запросы, есть что-то мелкое, а есть вообще просто непонимание со стороны пользователя. Для первых двух случаев обычно требуется оперативное вмешательство команды разработки.
Мы написали ИИ-агента в формате OpenAI Assistant, который мониторит канал в Slack и занимается первичной классификацией запросов. ИИ-агент знает все предыдущие переписки и легко находит схожие кейсы, предлагая уже существующее решение. Для новых кейсов ИИ-агент дозадаёт вопросы и заводит багу в JIRA. Затем тэгает нужную команду разработки.
И всё вроде хорошо, НО в таком формате отсутствует hard gate по заведению проблемы. То есть, например, CS написал о проблеме, бот дал совет, потом доспросил, и всё-таки выяснили, что это новая бага, и бот завёл её в JIRA. Время, пока бот доспрашивал и прояснял, а CS отвечал, могло затянуться на 2-3 дня.
И если проблема была важная — то потеряно время на её решение. Поэтому для важных проблем мы перешли на hard gate: жёсткая web-форма, которую нужно заполнить всю сразу, и мяч будет на стороне разработки только с момента сабмита формы.
Короче, процессы, где есть жёсткая передача ответственности по проблеме, лучше делать на hard gate (формах), а не на ботах, где есть мягкое длительное общение.
Подпишись 👉🏻 @aigentto 🤖
Каждый инструмент решает свою задачу. ИИ-агенты — очень мощный и гибкий инструмент, но есть кейсы, когда мы отказались от их использования.
У нас есть запросы от пользователей, которые приходят через команду Customer Success. Не все запросы одинаково важны: есть действительно критические кейсы, есть просто важные запросы, есть что-то мелкое, а есть вообще просто непонимание со стороны пользователя. Для первых двух случаев обычно требуется оперативное вмешательство команды разработки.
Мы написали ИИ-агента в формате OpenAI Assistant, который мониторит канал в Slack и занимается первичной классификацией запросов. ИИ-агент знает все предыдущие переписки и легко находит схожие кейсы, предлагая уже существующее решение. Для новых кейсов ИИ-агент дозадаёт вопросы и заводит багу в JIRA. Затем тэгает нужную команду разработки.
И всё вроде хорошо, НО в таком формате отсутствует hard gate по заведению проблемы. То есть, например, CS написал о проблеме, бот дал совет, потом доспросил, и всё-таки выяснили, что это новая бага, и бот завёл её в JIRA. Время, пока бот доспрашивал и прояснял, а CS отвечал, могло затянуться на 2-3 дня.
И если проблема была важная — то потеряно время на её решение. Поэтому для важных проблем мы перешли на hard gate: жёсткая web-форма, которую нужно заполнить всю сразу, и мяч будет на стороне разработки только с момента сабмита формы.
Короче, процессы, где есть жёсткая передача ответственности по проблеме, лучше делать на hard gate (формах), а не на ботах, где есть мягкое длительное общение.
Подпишись 👉🏻 @aigentto 🤖
🔥2
Хорошая подборка 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 🤖
Полезные для кодинга в 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 🤖
GitHub
GitHub - punkpeye/awesome-mcp-servers: A collection of MCP servers.
A collection of MCP servers. Contribute to punkpeye/awesome-mcp-servers development by creating an account on GitHub.
👍2
Как экономить время пользователей чатов и токены
Обычно при первом использовании chatGPT для ботов через API всем очень нравится его дикая вежливость.
Но когда уже запускается боевая RAG система на 3000–5000 человек, то, во-первых, вежливость начинает надоедать, потому что по сути не дает никакой доп. инфы. Плюс тратит на большом объеме драгоценные токены.
Поэтому поверх промта с контекстом и историей нужно давать system prompt, запрещающий трату токенов на бессмысленную вежливость. Пример на скрине.
Кстати, deepseek, YandexGPT и Gigachat по умолчанию не такие вежливые, и такой строгий запрет им может не понадобиться.
Подпишись 👉🏻 @aigentto 🤖
Обычно при первом использовании chatGPT для ботов через API всем очень нравится его дикая вежливость.
Но когда уже запускается боевая RAG система на 3000–5000 человек, то, во-первых, вежливость начинает надоедать, потому что по сути не дает никакой доп. инфы. Плюс тратит на большом объеме драгоценные токены.
Поэтому поверх промта с контекстом и историей нужно давать system prompt, запрещающий трату токенов на бессмысленную вежливость. Пример на скрине.
Кстати, deepseek, YandexGPT и Gigachat по умолчанию не такие вежливые, и такой строгий запрет им может не понадобиться.
Подпишись 👉🏻 @aigentto 🤖
❤2👍2
Вектризовать SQL бессмыслено
При создании RAG обычно используются статические данные, которые по сути являются просто текстом.
Следующим этапом обычно хочется создать бота, который будет отвечать не только на основании инструкций и документов компании, но и сможет строить аналитику по реальным боевым данным компании. На этом этапе многие берут SQL-данные и пытаются превратить их в статические текстовые данные (векторизовать). Это не будет работать, потому что нам нужны живые данные из SQL: там большой объем информации, много числовых данных, а не текста, а с числами семантические подходы работают плохо.
В такой ситуации необходимо реализовать MCP-сервер для SQL, который будет получать запрос от бота, использовать LLM для определения того, какие данные (таблицы) нужны. Если в базе данных много таблиц, потребуется отправлять LLM всю схему, поэтому здесь выгодно использовать, например, что-то вроде OpenAI Assistant с system prompt (для экономии токенов).
После того как LLM определит необходимые таблицы, мы запускаем SQL-запросы, собираем результаты и, например, используем pandas для аналитических выводов. Только эти выводы (результаты анализа) отправляются в LLM, чтобы она сформулировала итоговый ответ.
Дополнительно рекомендуется использовать MV (Materialized View), чтобы не перегружать базу данных запросами.
Таким образом, LLM здесь нужна только для понимания запроса пользователя, поиска таблиц с нужными данными и составления человеческого ответа на основании уже обработанных данных.
Подпишись 👉🏻 @aigentto 🤖
При создании RAG обычно используются статические данные, которые по сути являются просто текстом.
Следующим этапом обычно хочется создать бота, который будет отвечать не только на основании инструкций и документов компании, но и сможет строить аналитику по реальным боевым данным компании. На этом этапе многие берут SQL-данные и пытаются превратить их в статические текстовые данные (векторизовать). Это не будет работать, потому что нам нужны живые данные из SQL: там большой объем информации, много числовых данных, а не текста, а с числами семантические подходы работают плохо.
В такой ситуации необходимо реализовать MCP-сервер для SQL, который будет получать запрос от бота, использовать LLM для определения того, какие данные (таблицы) нужны. Если в базе данных много таблиц, потребуется отправлять LLM всю схему, поэтому здесь выгодно использовать, например, что-то вроде OpenAI Assistant с system prompt (для экономии токенов).
После того как LLM определит необходимые таблицы, мы запускаем SQL-запросы, собираем результаты и, например, используем pandas для аналитических выводов. Только эти выводы (результаты анализа) отправляются в LLM, чтобы она сформулировала итоговый ответ.
Дополнительно рекомендуется использовать MV (Materialized View), чтобы не перегружать базу данных запросами.
Таким образом, LLM здесь нужна только для понимания запроса пользователя, поиска таблиц с нужными данными и составления человеческого ответа на основании уже обработанных данных.
Подпишись 👉🏻 @aigentto 🤖
❤4👍1
Chain-of-thought промт для усиления целевого результата одним промтом
В одной RAG-системе есть довольно строгий промт и контекст. LLM отвечает, но иногда добавляет отсебятину, пытаясь быть полезной.
Инструкции в начале промта и даже в system prompt не всегда помогают.
Можно результат ещё раз валидировать через LLM или поиском лишних фраз в коде, но это требует дополнительного времени и токенов.
Чтобы получить всё по результатам первого запроса, можно добавить chain-of-thought промт — по сути, в конце, уже после промта и контекста, написать: «проанализируй свой ответ и проверь, что...».
Подпишись 👉🏻 @aigentto 🤖
В одной RAG-системе есть довольно строгий промт и контекст. LLM отвечает, но иногда добавляет отсебятину, пытаясь быть полезной.
Инструкции в начале промта и даже в system prompt не всегда помогают.
Можно результат ещё раз валидировать через LLM или поиском лишних фраз в коде, но это требует дополнительного времени и токенов.
Чтобы получить всё по результатам первого запроса, можно добавить chain-of-thought промт — по сути, в конце, уже после промта и контекста, написать: «проанализируй свой ответ и проверь, что...».
Подпишись 👉🏻 @aigentto 🤖
Файлы Термины.txt и КтоЕстьКто.txt
При внедрении RAG очень часто выясняется, что система не может отвечать на запросы с неформальными терминами. Причина проста: в официальных документах этих терминов нет, но они в ходу у сотрудников компании. То же самое касается должностей сотрудников компании: в документах может быть Иван Иваныч Иванов с должностью "руководитель по обеспечению материальными средствами", но сотрудники его ищут по "завхоз".
Выход прост: сразу создавайте два файла в хранилище, откуда RAG будет брать свои знания для векторизации. Файл Термины.txt — пишите сюда все неформальные термины, которые в ходу, и КтоЕстьКто.txt (или Сотрудники.txt) — пишите сюда все неформальные названия должностей сотрудников.
Формат файлов, конечно, лучше делать сразу в markdown — тогда вы минимизируете проблемы с пониманием ваших файлов со стороны LLM.
Подпишись 👉🏻 @aigentto 🤖
При внедрении RAG очень часто выясняется, что система не может отвечать на запросы с неформальными терминами. Причина проста: в официальных документах этих терминов нет, но они в ходу у сотрудников компании. То же самое касается должностей сотрудников компании: в документах может быть Иван Иваныч Иванов с должностью "руководитель по обеспечению материальными средствами", но сотрудники его ищут по "завхоз".
Выход прост: сразу создавайте два файла в хранилище, откуда RAG будет брать свои знания для векторизации. Файл Термины.txt — пишите сюда все неформальные термины, которые в ходу, и КтоЕстьКто.txt (или Сотрудники.txt) — пишите сюда все неформальные названия должностей сотрудников.
Формат файлов, конечно, лучше делать сразу в markdown — тогда вы минимизируете проблемы с пониманием ваших файлов со стороны LLM.
Подпишись 👉🏻 @aigentto 🤖
www.markdownguide.org
Basic Syntax | Markdown Guide
The Markdown elements outlined in the original design document.
❤6
Как тестировать качество ответов RAG/ИИ-агентов?
❗️Важно в начале при постановке задачи чётко определить, на какие вопросы система должна отвечать. В этом месте проваливается 50% внедрений, потому что обычно это выглядит так: надо, чтобы бот отвечал на вопросы по теме X, а потом ещё и по теме Y и т.д.
🚂 Составление конкретного списка вопросов и ожидаемых ответов заставляет раскрутить всю цепочку пайплайна бота:
👉 Но что он должен отвечать? Отвечать правду и по сути
👉 Где у нас источник этой правды? В документах
👉 Где эти документы? В каком они формате? Сколько их и про что они?
Самый простой вариант — это когда владельцы документов вручную берут и делают по два вопроса на каждый документ:
➕ Позитивный вопрос — ответ на который есть в конкретном документе.
➖ Негативный вопрос — вопрос по теме конкретного документа, ответа на который нет ни в этом документе, ни в других.
Дальше список вопросов автоматически (минуя цепочку бот→backend) можно прогонять при любых изменениях настроек llm, промта, контекста и делать скоринг:
+1 балл — ответил на вопрос,
0 баллов — не ответил на вопрос,
-1 балл — ответил на вопрос, но сказал неправду (галлюцинации).
И по каждой версии получаем общий score, который определяет её качество.
Для автогенерации таких вопросов и ответов мы уже сделали Python-код, надеюсь, скоро выложим в opensource.
Подпишись 👉🏻 @aigentto 🤖
❗️Важно в начале при постановке задачи чётко определить, на какие вопросы система должна отвечать. В этом месте проваливается 50% внедрений, потому что обычно это выглядит так: надо, чтобы бот отвечал на вопросы по теме X, а потом ещё и по теме Y и т.д.
🚂 Составление конкретного списка вопросов и ожидаемых ответов заставляет раскрутить всю цепочку пайплайна бота:
👉 Но что он должен отвечать? Отвечать правду и по сути
👉 Где у нас источник этой правды? В документах
👉 Где эти документы? В каком они формате? Сколько их и про что они?
Самый простой вариант — это когда владельцы документов вручную берут и делают по два вопроса на каждый документ:
➕ Позитивный вопрос — ответ на который есть в конкретном документе.
➖ Негативный вопрос — вопрос по теме конкретного документа, ответа на который нет ни в этом документе, ни в других.
Дальше список вопросов автоматически (минуя цепочку бот→backend) можно прогонять при любых изменениях настроек llm, промта, контекста и делать скоринг:
+1 балл — ответил на вопрос,
0 баллов — не ответил на вопрос,
-1 балл — ответил на вопрос, но сказал неправду (галлюцинации).
И по каждой версии получаем общий score, который определяет её качество.
Для автогенерации таких вопросов и ответов мы уже сделали Python-код, надеюсь, скоро выложим в opensource.
Подпишись 👉🏻 @aigentto 🤖
❤3
Риски RAG/ИИ-агентов
Самый банальный риск ИИ-агентов — это prompt injections.
Какие бы вы данные ни собирали как контекст, какой бы промт ни строили, простая инструкция в конце промта может сильно исказить результат ответа в ту или иную сторону.
В итоге вы получите ответ, который будет выглядеть хорошо, но не будет соответствовать правде. Инструкция, кстати, может идти не только текстом в промте, но и текстом в контексте или даже картинкой.
Поэтому промты нужно беречь от посторонних глаз, а доступ к их модификации давать только доверенным людям.
Плюс нужны security-гейты для валидации промтов, гейты на контекст, включая картинки, и гейты на проверку соответствия ответов llm запросу.
Подпишись 👉🏻 @aigentto 🤖
Самый банальный риск ИИ-агентов — это prompt injections.
Какие бы вы данные ни собирали как контекст, какой бы промт ни строили, простая инструкция в конце промта может сильно исказить результат ответа в ту или иную сторону.
В итоге вы получите ответ, который будет выглядеть хорошо, но не будет соответствовать правде. Инструкция, кстати, может идти не только текстом в промте, но и текстом в контексте или даже картинкой.
Поэтому промты нужно беречь от посторонних глаз, а доступ к их модификации давать только доверенным людям.
Плюс нужны security-гейты для валидации промтов, гейты на контекст, включая картинки, и гейты на проверку соответствия ответов llm запросу.
Подпишись 👉🏻 @aigentto 🤖
ИИ боты для замены покупателя
Сейчас разрабатывают много ботов от компаний для замены продавца. Но есть и другой тренд — боты для замены покупателя. Покупать что-то онлайн — это тоже время и боль, поэтому бот, который может сам найти что-то и купить за тебя в интернете, должен быть очень полезен.
К примеру, я вчера 2 часа потратил на бронирование перелётов на всю семью (и везде я смотрел доступность, вбивал одни и те же данные). Хорошо бы это полностью поручить боту. Он про меня всё знает (личные данные и предпочтения) и готов выполнять задания по покупкам.
Одна проблема — это рынок B2C, и здесь не ясно, кто за это и сколько будет платить. Скорее всего, все захотят такого бота бесплатно, тогда он будет вынужден монетизироваться через рекламу, то есть он станет аффилированным с конкретными поставщиками товаров. Либо покупай premium-версию, и бот будет на твоей стороне 😎
Подпишись 👉🏻 @aigentto 🤖
Сейчас разрабатывают много ботов от компаний для замены продавца. Но есть и другой тренд — боты для замены покупателя. Покупать что-то онлайн — это тоже время и боль, поэтому бот, который может сам найти что-то и купить за тебя в интернете, должен быть очень полезен.
К примеру, я вчера 2 часа потратил на бронирование перелётов на всю семью (и везде я смотрел доступность, вбивал одни и те же данные). Хорошо бы это полностью поручить боту. Он про меня всё знает (личные данные и предпочтения) и готов выполнять задания по покупкам.
Одна проблема — это рынок B2C, и здесь не ясно, кто за это и сколько будет платить. Скорее всего, все захотят такого бота бесплатно, тогда он будет вынужден монетизироваться через рекламу, то есть он станет аффилированным с конкретными поставщиками товаров. Либо покупай premium-версию, и бот будет на твоей стороне 😎
Подпишись 👉🏻 @aigentto 🤖