Если уже всё оптимизировали, но задержка ответа даже на 2-3 секунды критична, то переходим на streaming.
Дело в том, что все LLM генерируют текст последовательно (по токенам), и можно получать его либо как уже готовый результат, либо в процессе генерации. И выдавать его в адаптер (например, Telegram) в реальном времени. Тогда по сути будет иметь значение не полное время ответа, а только время реакции LLM, то есть время до начала генерации; дальше пользователь уже может читать ответ.
Узким местом здесь обычно становится адаптер (в нашем случае Telegram): выдавать посимвольно не получится, так как мы быстро упрёмся во flood limit, поэтому выдаём текст кусками на максимуме того, что может передать целевой адаптер.
Фактически здесь мы улучшаем скорость за счёт изменения UX.
Подпишись 👉🏻 @aigentto 🤖
Дело в том, что все LLM генерируют текст последовательно (по токенам), и можно получать его либо как уже готовый результат, либо в процессе генерации. И выдавать его в адаптер (например, Telegram) в реальном времени. Тогда по сути будет иметь значение не полное время ответа, а только время реакции LLM, то есть время до начала генерации; дальше пользователь уже может читать ответ.
Узким местом здесь обычно становится адаптер (в нашем случае Telegram): выдавать посимвольно не получится, так как мы быстро упрёмся во flood limit, поэтому выдаём текст кусками на максимуме того, что может передать целевой адаптер.
Фактически здесь мы улучшаем скорость за счёт изменения UX.
Подпишись 👉🏻 @aigentto 🤖
❤2
Тонкая настройка работы 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 🤖