Полезный AI генератор описания проекта git 👉 PocketFlow 👈 Выполняет то, что разработчики обычно делать не любят: генерирует очень хорошее описание каждого файла и общую диаграмму связей в формате Mermaid. GitHub и GitLab рендерят диаграму прямо внутри репозитория 🔥
Подключить можно любую LLM, и генерить на любом языке описание. Я пробовал с Gemini 2.5, отлично получилось.
Очень полезно для новых разработчиков на проекте: помогает понять, как всё работает, не отвлекая коллег 🧐 И для рефакторинга тоже полезен 🤔
Подпишись 👉🏻 @aigentto 🤖
Подключить можно любую LLM, и генерить на любом языке описание. Я пробовал с Gemini 2.5, отлично получилось.
Очень полезно для новых разработчиков на проекте: помогает понять, как всё работает, не отвлекая коллег 🧐 И для рефакторинга тоже полезен 🤔
Подпишись 👉🏻 @aigentto 🤖
👍2❤1
Audio
Подкаст на основе последней статьи по теме "Как сделать RAG систему для своей компании". Для тех кому проще послушать, чем читать.
Сделано на основе https://notebooklm.google.com, очень удобно. Я, когда большую статью лень читать, делаю такой подкаст и слушаю, когда бегаю. Любая тема, озвученная в ролях, намного легче заходит, потом всегда можно посмотреть в статье точечно то, что заинтересовало. Рекомендую ➕➕➕
Подпишись 👉🏻 @aigentto 🤖
Сделано на основе https://notebooklm.google.com, очень удобно. Я, когда большую статью лень читать, делаю такой подкаст и слушаю, когда бегаю. Любая тема, озвученная в ролях, намного легче заходит, потом всегда можно посмотреть в статье точечно то, что заинтересовало. Рекомендую ➕➕➕
Подпишись 👉🏻 @aigentto 🤖
👍3🔥3
Ограничения инфраструктуры OpenAI
Сейчас помогаем делать RAG-систему для одной российской компании, которая уже использует OpenAI. Хотели перевести всё на рельсы AI Assistants + vectorstore, но передумали...
Дело в том, что у ребят есть довольно хорошая схема сбора обратной связи: после каждого ответа боту в Telegram можно поставить like или dislike. Это, в свою очередь, меняет вес для выбранных векторов по запросу - либо понижает (dislike), либо повышает (like).
Сделать подобную манипуляцию в OpenAI vectorstore нельзя - это blackbox. Туда можно только загрузить данные, а управлять выборкой будет сам OpenAI, что удобно, но лишает вас тонкой настройки.
А фича сбора обратной связи очень полезная, поэтому будем делать локальную векторную БД. При этом будем использовать OpenAI Assistants, скармливая ему выборку векторов, веса которых мы будем менять в зависимости от обратной связи пользователей.
Таким образом, у нас будет память от OpenAI (threads) и разбивка по ассистентам, что позволит избежать использования других фреймворков типа LangChain и AutoGen.
Берём лучшее из возможного, и всегда помним о ключевом принципе инженерии - best part is no part (лучшая часть - это отсутствие этой части).
Подпишись 👉🏻 @aigentto 🤖
Сейчас помогаем делать RAG-систему для одной российской компании, которая уже использует OpenAI. Хотели перевести всё на рельсы AI Assistants + vectorstore, но передумали...
Дело в том, что у ребят есть довольно хорошая схема сбора обратной связи: после каждого ответа боту в Telegram можно поставить like или dislike. Это, в свою очередь, меняет вес для выбранных векторов по запросу - либо понижает (dislike), либо повышает (like).
Сделать подобную манипуляцию в OpenAI vectorstore нельзя - это blackbox. Туда можно только загрузить данные, а управлять выборкой будет сам OpenAI, что удобно, но лишает вас тонкой настройки.
А фича сбора обратной связи очень полезная, поэтому будем делать локальную векторную БД. При этом будем использовать OpenAI Assistants, скармливая ему выборку векторов, веса которых мы будем менять в зависимости от обратной связи пользователей.
Таким образом, у нас будет память от OpenAI (threads) и разбивка по ассистентам, что позволит избежать использования других фреймворков типа LangChain и AutoGen.
Берём лучшее из возможного, и всегда помним о ключевом принципе инженерии - best part is no part (лучшая часть - это отсутствие этой части).
Подпишись 👉🏻 @aigentto 🤖
👍3❤1
Вышла статья Как сделать RAG/ИИ-Асистента без кода 🔥
Делаем генератор постов для канала📖, поиск рейсов ✈️ и бронирование отелей через Yandex Travel API 🛎
Подпишись 👉🏻 @aigentto 🤖
Делаем генератор постов для канала📖, поиск рейсов ✈️ и бронирование отелей через Yandex Travel API 🛎
Подпишись 👉🏻 @aigentto 🤖
Хабр
Как сделать RAG/ИИ-ассистента без кода
Если вам нужно сконфигурировать персонального или командного AI-ассистента без единой строчки кода, то инфраструктура OpenAI позволяет это сделать. В этой статье мы сконфигурируем ассистента для...
🔥4
В создании ассистентов и RAG-систем очень важно понимать цель — от этого сильно зависят архитектура и инструменты.
Из цели вытекают наши явные и неявные потребности, под которые подбираются соответствующие инструменты. Если для вас критична скорость ответа (секунды), использовать OpenAI Assistant — не лучший вариант. Лучше локальная векторная база данных и быстрая модель. В этом случае придётся самостоятельно реализовать локальное хранение данных и другие компоненты — кода будет значительно больше, а поддержка сложнее.
Например, если мы делаем клона сотрудника или команды, можно использовать OpenAI Assistants вместе с OpenAI vectorstore, обновляя vectorstore раз в день или чаще. Ведь мы не ожидаем, что реальный сотрудник ответит на сообщение в Slack за 2 секунды, поэтому подождать 5–20 секунд вполне нормально.
Второй пример: если мы делаем WikiBot или JIRABot, который должен интерактивно искать по Wiki или JIRA, здесь важна актуальность постоянно меняющейся информации. При этом подождать качественного ответа 5–20 секунд тоже приемлемо.
Если же данные RAG-системы почти не меняются (обновляются редко), актуальность не так важна, а объём данных небольшой (например, система адаптации нового сотрудника), но хочется, чтобы бот отвечал быстро (1–3 секунды), а пользователей тысячи, инфраструктура OpenAI Assistant может не подойти — это «чёрный ящик», в том числе по скорости.
Но можно реализовать семантический кэш: бот будет задумываться только при первом обращении с новым вопросом, а затем брать ответ из кэша, не обращаясь к Assistant.
Если же актуальность критична, документов и пользователей много, и требуется быстрый ответ — OpenAI не подходит совсем. Здесь лучше использовать локальный фреймворк, например, LangChain.
Подпишись 👉🏻 @aigentto 🤖
Из цели вытекают наши явные и неявные потребности, под которые подбираются соответствующие инструменты. Если для вас критична скорость ответа (секунды), использовать OpenAI Assistant — не лучший вариант. Лучше локальная векторная база данных и быстрая модель. В этом случае придётся самостоятельно реализовать локальное хранение данных и другие компоненты — кода будет значительно больше, а поддержка сложнее.
Например, если мы делаем клона сотрудника или команды, можно использовать OpenAI Assistants вместе с OpenAI vectorstore, обновляя vectorstore раз в день или чаще. Ведь мы не ожидаем, что реальный сотрудник ответит на сообщение в Slack за 2 секунды, поэтому подождать 5–20 секунд вполне нормально.
Второй пример: если мы делаем WikiBot или JIRABot, который должен интерактивно искать по Wiki или JIRA, здесь важна актуальность постоянно меняющейся информации. При этом подождать качественного ответа 5–20 секунд тоже приемлемо.
Если же данные RAG-системы почти не меняются (обновляются редко), актуальность не так важна, а объём данных небольшой (например, система адаптации нового сотрудника), но хочется, чтобы бот отвечал быстро (1–3 секунды), а пользователей тысячи, инфраструктура OpenAI Assistant может не подойти — это «чёрный ящик», в том числе по скорости.
Но можно реализовать семантический кэш: бот будет задумываться только при первом обращении с новым вопросом, а затем брать ответ из кэша, не обращаясь к Assistant.
Если же актуальность критична, документов и пользователей много, и требуется быстрый ответ — OpenAI не подходит совсем. Здесь лучше использовать локальный фреймворк, например, LangChain.
Подпишись 👉🏻 @aigentto 🤖
👍5🔥1
Если уже всё оптимизировали, но задержка ответа даже на 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