Как сделать ИИ-агента умнее?
Бывает, что ИИ-агент, обученный на документах компании, тупит и многого не знает. Стандартная причина в том, что в документах есть слепок прошлого, а в компании уже многое поменялось и появились новые правила, процессы. Обновлять документы в большой компании — это опять процедура на 3-6 месяцев.
Но есть способ проще — берем ответственных за каждую область и садим их поговорить с ботом (ИИ-агентом) на свою тему. Специалист в своей области быстро выявит места, где у бота неактуальная или неверная информация, и прямо в чате ему скажет: "Вот это не так — а вот так".
Затем берем список никнеймов специалистов и выгружаем все диалоги за этот день, загоняем в LLM и просим создать из этого красивый FAQ в md формате. И подкладываем этот FAQ в базу знаний бота.
Дополнительно можно еще провести кросс-анализ и вычистить старую инфу или даже напрямую автоматом обновить старые документы.
Процедура занимает 1-2 дня.
Подпишись 👉🏻 @aigentto 🤖
Бывает, что ИИ-агент, обученный на документах компании, тупит и многого не знает. Стандартная причина в том, что в документах есть слепок прошлого, а в компании уже многое поменялось и появились новые правила, процессы. Обновлять документы в большой компании — это опять процедура на 3-6 месяцев.
Но есть способ проще — берем ответственных за каждую область и садим их поговорить с ботом (ИИ-агентом) на свою тему. Специалист в своей области быстро выявит места, где у бота неактуальная или неверная информация, и прямо в чате ему скажет: "Вот это не так — а вот так".
Затем берем список никнеймов специалистов и выгружаем все диалоги за этот день, загоняем в LLM и просим создать из этого красивый FAQ в md формате. И подкладываем этот FAQ в базу знаний бота.
Дополнительно можно еще провести кросс-анализ и вычистить старую инфу или даже напрямую автоматом обновить старые документы.
Процедура занимает 1-2 дня.
Подпишись 👉🏻 @aigentto 🤖
👍4🤔1
Хрупкость всех agentic систем
Во всех мультиагентных системах есть одно хрупкое место — это протокол общения между агентами или роутинг между ними.
По сути, можно сделать жёсткий роутинг прямо в коде. Можно сделать условный роутинг тоже в коде. А можно настроить гибкий роутинг во фреймворках AutoGen, LangChain. Но даже в гибких вариантах это определённая договорённость (правила общения).
Хрупкость в том, что агенты используют LLM, которая может вернуть не совсем то, что ожидается, и да, конечно, они должны валидировать то, что им возвращает LLM, а потом передавать данные следующему агенту в строго определённом формате. Любое изменение кода, промтов и прочего может поломать цепочку. Неожиданный ответ LLM может поломать цепочку. Изменения API вендоров могут поломать одного агента и поломать цепочку.
Это всё норма в мире технологий прошлого, где не было LLM. Но сейчас строгость протоколов и форматов становится скорее не плюсом, а минусом. Ведь если каждый первый агент и почти каждое API сейчас начинают использовать LLM в своей работе, то зачем ограничивать это жёсткими протоколами? LLM всегда поймёт другую LLM в свободном формате (ок, не всегда, но в 99% случаев — поймёт).
Поэтому мир будет двигаться от строго определённых протоколов к гибким и даже к отсутствию протоколов.
Мы провели эксперимент — попробовали загнать множество разных агентов в пространство без протоколов и дали им возможность общаться на человеческом языке, и они отлично справляются. Агенты читают этот общий чат и публикуют свои результаты и наблюдения обратно. В этом, казалось бы, мусоре сообщений возникает чёткое общение и выполнение целей агентов. Без роутинга, без протокола.
Более детально про результаты нашего эксперимента скоро будет статья на habr.
Подпишись 👉🏻 @aigentto 🤖
Во всех мультиагентных системах есть одно хрупкое место — это протокол общения между агентами или роутинг между ними.
По сути, можно сделать жёсткий роутинг прямо в коде. Можно сделать условный роутинг тоже в коде. А можно настроить гибкий роутинг во фреймворках AutoGen, LangChain. Но даже в гибких вариантах это определённая договорённость (правила общения).
Хрупкость в том, что агенты используют LLM, которая может вернуть не совсем то, что ожидается, и да, конечно, они должны валидировать то, что им возвращает LLM, а потом передавать данные следующему агенту в строго определённом формате. Любое изменение кода, промтов и прочего может поломать цепочку. Неожиданный ответ LLM может поломать цепочку. Изменения API вендоров могут поломать одного агента и поломать цепочку.
Это всё норма в мире технологий прошлого, где не было LLM. Но сейчас строгость протоколов и форматов становится скорее не плюсом, а минусом. Ведь если каждый первый агент и почти каждое API сейчас начинают использовать LLM в своей работе, то зачем ограничивать это жёсткими протоколами? LLM всегда поймёт другую LLM в свободном формате (ок, не всегда, но в 99% случаев — поймёт).
Поэтому мир будет двигаться от строго определённых протоколов к гибким и даже к отсутствию протоколов.
Мы провели эксперимент — попробовали загнать множество разных агентов в пространство без протоколов и дали им возможность общаться на человеческом языке, и они отлично справляются. Агенты читают этот общий чат и публикуют свои результаты и наблюдения обратно. В этом, казалось бы, мусоре сообщений возникает чёткое общение и выполнение целей агентов. Без роутинга, без протокола.
Более детально про результаты нашего эксперимента скоро будет статья на habr.
Подпишись 👉🏻 @aigentto 🤖
🔥5
Вышел RAG ChunkTester
Это фреймворк для автоматического тестирования качества Retrieval-Augmented Generation систем.
Он позволяет быстро оценивать влияние разных стратегий чанкования, настройки эмбеддинга, параметров ретривера и промпта.
Как работает я описывал тут https://habr.com/ru/articles/930008/
Доступен тут https://github.com/alx1379/ChunkTester.
Лицензия Appache-2.0.
Подпишись 👉🏻 @aigentto 🤖
Это фреймворк для автоматического тестирования качества Retrieval-Augmented Generation систем.
Он позволяет быстро оценивать влияние разных стратегий чанкования, настройки эмбеддинга, параметров ретривера и промпта.
Как работает я описывал тут https://habr.com/ru/articles/930008/
Доступен тут https://github.com/alx1379/ChunkTester.
Лицензия Appache-2.0.
Подпишись 👉🏻 @aigentto 🤖
Хабр
Как тестировать качество ответов RAG системы?
LLM могут принимать на вход все большее количество токенов, но большое количество переданных на вход токенов, включая промт, контекст и историю переписки, не равно качеству ответа. В идеале на вход...
❤2🔥2
Информационные пузыри в нейросетях
Мы все давно живём в своих инфопузырях. Google/Yandex выдаёт на один и тот же запрос немного разный список линков, подстроенный под вас, социальные сети и видеосервисы выдают нашу ленту. И реклама у нас у каждого уже своя. Это и есть информационный пузырь для каждого из нас — мы получаем не фактически нейтральную информацию, а подстроенную под нас.
В нейросетях это проявляется тем, что LLM знает контекст нашей переписки и будет тоже подстраивать ответы под нас, поэтому для фактологических сервисов (типа RAG-систем) важно для сохранения объективности правильно выстраивать промты, давать минимально нужный контекст и задавать немотивированные вопросы.
Самый банальный пример — это вопрос типа: «Подскажи, какую мне выбрать машину? Мне вообще нравится Toyota, что думаешь?». В ответ на это LLM начнёт рассуждать о Toyota, вместо нейтрального качественного сравнения, потому что вы задаёте вектор разговора, и в LLM это не метафора — весь текст будет переведён в вектор, и избавиться от направления Toyota в этом разговоре уже не удастся.
Для избегания эффекта пузыря вопрос нужно задавать так: «Подскажи, какую мне выбрать машину? Я буду ездить от дома до работы 5 дней в неделю один, и на выходные возить семью (4 человека) погулять в город». То есть мы задаём условия, но не задаём вектор выбора (Toyota).
Подпишись 👉🏻 @aigentto 🤖
Мы все давно живём в своих инфопузырях. Google/Yandex выдаёт на один и тот же запрос немного разный список линков, подстроенный под вас, социальные сети и видеосервисы выдают нашу ленту. И реклама у нас у каждого уже своя. Это и есть информационный пузырь для каждого из нас — мы получаем не фактически нейтральную информацию, а подстроенную под нас.
В нейросетях это проявляется тем, что LLM знает контекст нашей переписки и будет тоже подстраивать ответы под нас, поэтому для фактологических сервисов (типа RAG-систем) важно для сохранения объективности правильно выстраивать промты, давать минимально нужный контекст и задавать немотивированные вопросы.
Самый банальный пример — это вопрос типа: «Подскажи, какую мне выбрать машину? Мне вообще нравится Toyota, что думаешь?». В ответ на это LLM начнёт рассуждать о Toyota, вместо нейтрального качественного сравнения, потому что вы задаёте вектор разговора, и в LLM это не метафора — весь текст будет переведён в вектор, и избавиться от направления Toyota в этом разговоре уже не удастся.
Для избегания эффекта пузыря вопрос нужно задавать так: «Подскажи, какую мне выбрать машину? Я буду ездить от дома до работы 5 дней в неделю один, и на выходные возить семью (4 человека) погулять в город». То есть мы задаём условия, но не задаём вектор выбора (Toyota).
Подпишись 👉🏻 @aigentto 🤖
👍2
Промт для извлечения эмоций
Недавно писал про то, как мало фактов в чатах и как много там эмоций.
Вот полезный промт для извлечения эмоций и тем из чатов:
Подпишись 👉🏻 @aigentto 🤖
Недавно писал про то, как мало фактов в чатах и как много там эмоций.
Вот полезный промт для извлечения эмоций и тем из чатов:
Ты — аналитик по эмоциям и темам чатов.
Я передам тебе переписку, а твоя задача:
1. Для каждого сообщения определить эмоцию (или несколько эмоций) из списка: [радость, интерес, удивление, грусть, злость, раздражение, страх, тревога, нейтральное].
2. Определить тему сообщения (например: работа, личные отношения, проект, деньги, отдых, здоровье и т.д.).
3. Сгруппировать сообщения по темам и подсчитать частоту каждой эмоции внутри темы.
4. Вернуть результат в структурированном JSON формате, пригодном для построения графика «Тема vs Эмоции».
Формат ответа:
{
"topics": [
{
"topic": "название темы",
"emotions": {
"радость": число,
"интерес": число,
"удивление": число,
"грусть": число,
"злость": число,
"раздражение": число,
"страх": число,
"тревога": число,
"нейтральное": число
}
},
...
]
}
Теперь обработай этот чат:
[ВСТАВЬ ТЕКСТ ПЕРЕПИСКИ]
Подпишись 👉🏻 @aigentto 🤖
Telegram
AIGENTTO
Плотность полезной информации в чатах
Дополнительным источником информации для базы знаний бота по компании могут быть переписки сотрудников в чатах. Если переписок много и они качественные (вопросы и ответы по теме), то это может стать и начальной базой…
Дополнительным источником информации для базы знаний бота по компании могут быть переписки сотрудников в чатах. Если переписок много и они качественные (вопросы и ответы по теме), то это может стать и начальной базой…
👍3
LLM спасет локальный debug
Раньше, когда я писал на C/C++, я всегда делал локальный пошаговый debug с отсмотром всех переменных для понимания, где может быть проблема. Сейчас почти никто так не делает, тем более что это все усложняется необходимостью написания большого числа заглушек для такого дебага.
Это был очень мощный инструмент, НО сейчас есть LLM, и простое скармливание кода с просьбой дебагинга находит 90% потенциальных проблем 👏
Подпишись 👉🏻 @aigentto 🤖
Раньше, когда я писал на C/C++, я всегда делал локальный пошаговый debug с отсмотром всех переменных для понимания, где может быть проблема. Сейчас почти никто так не делает, тем более что это все усложняется необходимостью написания большого числа заглушек для такого дебага.
Это был очень мощный инструмент, НО сейчас есть LLM, и простое скармливание кода с просьбой дебагинга находит 90% потенциальных проблем 👏
Подпишись 👉🏻 @aigentto 🤖
Очень лёгкий фреймворк (low-code) для Agentic AI
Наткнулся на очень простой фрейм для создания мультиагентных систем. Намного проще, легче и красивее, чем LangChain, AutoGen и прочие монстры.
Там уже есть правила для Cursor, Windsurf, Claude и прочих LLM IDE.
По сути, просто загружаешь в том же Cursor и говоришь, что нужно сделать, — и оно собирает достаточно сложную мультиагентную систему за 5 минут. В no-code решения я не верю, но low-code типа этого реально работают.
Подпишись 👉🏻 @aigentto 🤖
Наткнулся на очень простой фрейм для создания мультиагентных систем. Намного проще, легче и красивее, чем LangChain, AutoGen и прочие монстры.
Там уже есть правила для Cursor, Windsurf, Claude и прочих LLM IDE.
По сути, просто загружаешь в том же Cursor и говоришь, что нужно сделать, — и оно собирает достаточно сложную мультиагентную систему за 5 минут. В no-code решения я не верю, но low-code типа этого реально работают.
Подпишись 👉🏻 @aigentto 🤖
GitHub
GitHub - The-Pocket/PocketFlow-Template-Python: Pocket Flow Project Template: Agentic Coding for Python
Pocket Flow Project Template: Agentic Coding for Python - The-Pocket/PocketFlow-Template-Python
🔥3🤔1
Инструкции для LLM нельзя положить в RAG
Часто RAG пытаются применить там, где он не нужен, например, когда есть большой набор примеров или методик, по которым мы хотим, чтобы LLM строила ответы. То есть мы хотим дать на вход большую инструкцию и заставить LLM, руководствуясь большим объемом примеров о том, как надо делать, либо большим объемом теории (методики), выдать результат.
Из-за того, что в этом случае мы имеем большой объем примеров или методик, которые определяют руководство к действию для LLM, мы начинаем думать, что по причине того, что это нельзя впихнуть в промт, надо прикрутить RAG и выбирать часть (top-k) примеров и методик, которые наиболее семантически сходны с поданным контекстом (запросом пользователя, например). Это ошибка!
Только лишь потому, что наша инструкция (примеры и методики) объемные, впихивание их в RAG не только ничего не даст, оно поломает нашу логику, потому что инструкция (какой длины бы она ни была) должна быть полностью передана в LLM. А когда мы получаем куски инструкции, по семантике схожие с поданным контекстом, мы получаем полную ерунду.
Важно понять, что RAG — это про выборку фактов из большого количества данных, именно фактов! Выбирать динамически инструкцию для LLM — это не RAG, и это работать не будет! Инструкция, какой бы длины она ни была, подаётся всегда полностью со всеми примерами, контекст выбирается под запрос по семантике.
Поэтому надо искать способ подать это всё как инструкцию, способов много:
1. Подумать, а нужны ли все примеры? И сделать few-shots, то есть несколько разных примеров того, что мы хотим получить.
2. Использовать LLM для уменьшения объема нашей инструкции (LLM очень хорошо умеет ужимать смысл, сохраняя суть).
3. Использовать подачу инструкции частями и отдельно контекст, сообщить LLM о том, что мы будем делать это частями и пока не скажем GO, она не должна давать ответ.
Подпишись 👉🏻 @aigentto 🤖
Часто RAG пытаются применить там, где он не нужен, например, когда есть большой набор примеров или методик, по которым мы хотим, чтобы LLM строила ответы. То есть мы хотим дать на вход большую инструкцию и заставить LLM, руководствуясь большим объемом примеров о том, как надо делать, либо большим объемом теории (методики), выдать результат.
Из-за того, что в этом случае мы имеем большой объем примеров или методик, которые определяют руководство к действию для LLM, мы начинаем думать, что по причине того, что это нельзя впихнуть в промт, надо прикрутить RAG и выбирать часть (top-k) примеров и методик, которые наиболее семантически сходны с поданным контекстом (запросом пользователя, например). Это ошибка!
Только лишь потому, что наша инструкция (примеры и методики) объемные, впихивание их в RAG не только ничего не даст, оно поломает нашу логику, потому что инструкция (какой длины бы она ни была) должна быть полностью передана в LLM. А когда мы получаем куски инструкции, по семантике схожие с поданным контекстом, мы получаем полную ерунду.
Важно понять, что RAG — это про выборку фактов из большого количества данных, именно фактов! Выбирать динамически инструкцию для LLM — это не RAG, и это работать не будет! Инструкция, какой бы длины она ни была, подаётся всегда полностью со всеми примерами, контекст выбирается под запрос по семантике.
Поэтому надо искать способ подать это всё как инструкцию, способов много:
1. Подумать, а нужны ли все примеры? И сделать few-shots, то есть несколько разных примеров того, что мы хотим получить.
2. Использовать LLM для уменьшения объема нашей инструкции (LLM очень хорошо умеет ужимать смысл, сохраняя суть).
3. Использовать подачу инструкции частями и отдельно контекст, сообщить LLM о том, что мы будем делать это частями и пока не скажем GO, она не должна давать ответ.
Подпишись 👉🏻 @aigentto 🤖
LLM архиватор
Как я уже писал ранее, в информации, которой обмениваются люди, зачастую очень много шума и мало смысла. Поэтому любой текст можно сильно ужать, попросив об этом LLM. При этом смысл и факты останутся.
Таким образом LLM может выступать архиватором смыслов. Это может быть полезно для сохранения фактов из переписок, встреч, протоколов и т.д.
Это также может быть очень полезно для уменьшения контекста, подаваемого на вход LLM при повторном запросе, то есть, например, у вас есть переписка с пользователем на сотни сообщений, и вы, желая сохранить весь контекст, передаете всю историю переписки при каждом новом вопросе пользователя.
Вы тратите много токенов и заставляете LLM тормозить, разбирая заново весь ваш большой контекст. Вместо этого берёте историю в сотни сообщений и просите LLM написать коротко все факты из переписки (будут как минимум удалены все дубли и подобраны более короткие формулировки). Получаете экономию токенов и более быстрый ответ LLM.
Подпишись 👉🏻 @aigentto 🤖
Как я уже писал ранее, в информации, которой обмениваются люди, зачастую очень много шума и мало смысла. Поэтому любой текст можно сильно ужать, попросив об этом LLM. При этом смысл и факты останутся.
Таким образом LLM может выступать архиватором смыслов. Это может быть полезно для сохранения фактов из переписок, встреч, протоколов и т.д.
Это также может быть очень полезно для уменьшения контекста, подаваемого на вход LLM при повторном запросе, то есть, например, у вас есть переписка с пользователем на сотни сообщений, и вы, желая сохранить весь контекст, передаете всю историю переписки при каждом новом вопросе пользователя.
Вы тратите много токенов и заставляете LLM тормозить, разбирая заново весь ваш большой контекст. Вместо этого берёте историю в сотни сообщений и просите LLM написать коротко все факты из переписки (будут как минимум удалены все дубли и подобраны более короткие формулировки). Получаете экономию токенов и более быстрый ответ LLM.
Подпишись 👉🏻 @aigentto 🤖
Telegram
AIGENTTO
Плотность полезной информации в чатах
Дополнительным источником информации для базы знаний бота по компании могут быть переписки сотрудников в чатах. Если переписок много и они качественные (вопросы и ответы по теме), то это может стать и начальной базой…
Дополнительным источником информации для базы знаний бота по компании могут быть переписки сотрудников в чатах. Если переписок много и они качественные (вопросы и ответы по теме), то это может стать и начальной базой…
👍1
Отвечаю на вопрос по извлечению фактов из чатов и текстов
Всё намного банальнее в реальности. Вот тут реальный кейс компании: ~10 000 сообщений, ~700 участников, 28 реальных вопросов-ответов, 25 реально недублирующихся устойчивых фактов. Всё остальное — шум типа «привет, пока, а как, а че, я тут подумал»...
LLM это выделяет очень хорошо. Конечно, важен промт.
Мы сейчас тестируем новый подход, в том числе к индексированию документов (Factology) — выделение фактов вместо простого чанкования. Как выяснилось, в документах тоже очень много воды и дубликатов.
И если в переписке был упомянут промт как промт, то в нашем случае LLM его сохранит как факт.
Главное — не переоценивать плотность информации в переписках и даже документах: там очень-очень-очень много воды. Нам людям так удобнее общаться, но для LLM это лишний шум.
А если надо извлечь эмоции из чатов, то это тоже можно сделать и отдельно сохранить, не держа весь объём переписок.
Подпишись 👉🏻 @aigentto 🤖
Всё намного банальнее в реальности. Вот тут реальный кейс компании: ~10 000 сообщений, ~700 участников, 28 реальных вопросов-ответов, 25 реально недублирующихся устойчивых фактов. Всё остальное — шум типа «привет, пока, а как, а че, я тут подумал»...
LLM это выделяет очень хорошо. Конечно, важен промт.
Мы сейчас тестируем новый подход, в том числе к индексированию документов (Factology) — выделение фактов вместо простого чанкования. Как выяснилось, в документах тоже очень много воды и дубликатов.
И если в переписке был упомянут промт как промт, то в нашем случае LLM его сохранит как факт.
Главное — не переоценивать плотность информации в переписках и даже документах: там очень-очень-очень много воды. Нам людям так удобнее общаться, но для LLM это лишний шум.
А если надо извлечь эмоции из чатов, то это тоже можно сделать и отдельно сохранить, не держа весь объём переписок.
Подпишись 👉🏻 @aigentto 🤖
Telegram
AIGENTTO
Плотность полезной информации в чатах
Дополнительным источником информации для базы знаний бота по компании могут быть переписки сотрудников в чатах. Если переписок много и они качественные (вопросы и ответы по теме), то это может стать и начальной базой…
Дополнительным источником информации для базы знаний бота по компании могут быть переписки сотрудников в чатах. Если переписок много и они качественные (вопросы и ответы по теме), то это может стать и начальной базой…
👍4
Agentic AGI
Посмотрел все доклады John Carmack по его работе в направлении AGI.
И понял, что реальные ИИ-агенты не должны работать в стерильных условиях (известные протоколы, чёткое разделение функций и последовательность выполнения и т.д.). Реальные ИИ-агенты должны уметь выживать в noisy environments (шумных средах), иначе они никогда не обойдут простого секретаря по эффективности.
Мы уже ведём тестирование общения агентов в среде без протокола (результаты хорошие).
В этих средах мы добавляем лишних агентов, которые создают шум (шутят шутки, рекламируют себя и т.д.). Это сильно помогает сделать боевых агентов более устойчивыми.
Надеюсь, скоро будет детальная статья по результатам.
Подпишись 👉🏻 @aigentto 🤖
Посмотрел все доклады John Carmack по его работе в направлении AGI.
И понял, что реальные ИИ-агенты не должны работать в стерильных условиях (известные протоколы, чёткое разделение функций и последовательность выполнения и т.д.). Реальные ИИ-агенты должны уметь выживать в noisy environments (шумных средах), иначе они никогда не обойдут простого секретаря по эффективности.
Мы уже ведём тестирование общения агентов в среде без протокола (результаты хорошие).
В этих средах мы добавляем лишних агентов, которые создают шум (шутят шутки, рекламируют себя и т.д.). Это сильно помогает сделать боевых агентов более устойчивыми.
Надеюсь, скоро будет детальная статья по результатам.
Подпишись 👉🏻 @aigentto 🤖
Telegram
AIGENTTO
Хрупкость всех agentic систем
Во всех мультиагентных системах есть одно хрупкое место — это протокол общения между агентами или роутинг между ними.
По сути, можно сделать жёсткий роутинг прямо в коде. Можно сделать условный роутинг тоже в коде. А можно…
Во всех мультиагентных системах есть одно хрупкое место — это протокол общения между агентами или роутинг между ними.
По сути, можно сделать жёсткий роутинг прямо в коде. Можно сделать условный роутинг тоже в коде. А можно…
🔥3🤔1
Эволюция ИИ-агентов
Уровень 1
Можно создать одного агента с большим промтом под разные задачи. Будет много глюков и постоянное перетягивание промтов агента для выполнения одной задачи лучше другой.
Уровень 2
Можно разделить на X агентов по чётким задачам (один пишет статью, другой её проверяет, третий добавляет нативную рекламу и т.д.). Это будет работать лучше, но жёсткая связка агентов и однозначность их промтов не дают этой конструкции расти и улучшать свои результаты.
Уровень 3
Рои микроагентов под микро-задачи с общением без протокола. Работает так же хорошо, как уровень 2, но позволяет агентам выстраивать новые более эффективные связи в зависимости от задачи.
Уровень 4
Рои генерируемых микроагентов одним god-agent под задачу. Лучше, чем уровень 3, потому что всё начинается с чистого листа, и система сама создаст нужное количество агентов под входящие задачи.
Уровень 5
Рои генерируемых эволюционирующих агентов. То же, что уровень 4, но с отбором лучших, cross-over, mutation, как в генетических алгоритмах. Тут мы уже подходим к Agentic AGI 🤖.
Подпишись 👉🏻 @aigentto 🤖
Уровень 1
Можно создать одного агента с большим промтом под разные задачи. Будет много глюков и постоянное перетягивание промтов агента для выполнения одной задачи лучше другой.
Уровень 2
Можно разделить на X агентов по чётким задачам (один пишет статью, другой её проверяет, третий добавляет нативную рекламу и т.д.). Это будет работать лучше, но жёсткая связка агентов и однозначность их промтов не дают этой конструкции расти и улучшать свои результаты.
Уровень 3
Рои микроагентов под микро-задачи с общением без протокола. Работает так же хорошо, как уровень 2, но позволяет агентам выстраивать новые более эффективные связи в зависимости от задачи.
Уровень 4
Рои генерируемых микроагентов одним god-agent под задачу. Лучше, чем уровень 3, потому что всё начинается с чистого листа, и система сама создаст нужное количество агентов под входящие задачи.
Уровень 5
Рои генерируемых эволюционирующих агентов. То же, что уровень 4, но с отбором лучших, cross-over, mutation, как в генетических алгоритмах. Тут мы уже подходим к Agentic AGI 🤖.
Подпишись 👉🏻 @aigentto 🤖
👍4
Clusteroid для автокластеризации документов в RAG
В RAG часто бывает набор различных документов из разных департаментов компании. Нужно либо использовать разделение на кластеры по департаментам, что часто бывает неточным (например, в HR хранится много разных по типу и содержанию документов), либо сортировать их самостоятельно. Либо же сложить всё вместе в одну кучу.
Третий вариант — самый плохой, так как получится много схожей семантики, и процесс retrieve будет работать плохо (будет попадать много нерелевантных чанков). Первый вариант обычно приемлем, но по сути сводится ко второму: нужен человек, который вручную качественно сортировал бы документы по секциям и пересортировывал при изменениях и добавлениях.
Существуют библиотеки, например, SpaCy, которые могут делать разметку (NER), но без качественной настройки под конкретную тему они работают плохо.
Поэтому мы разработали собственный кластеризатор Clusteroid, который выложили в open source. Он умеет кластеризовать с помощью K-Means или HDBSCAN.
Подпишись 👉🏻 @aigentto 🤖
В RAG часто бывает набор различных документов из разных департаментов компании. Нужно либо использовать разделение на кластеры по департаментам, что часто бывает неточным (например, в HR хранится много разных по типу и содержанию документов), либо сортировать их самостоятельно. Либо же сложить всё вместе в одну кучу.
Третий вариант — самый плохой, так как получится много схожей семантики, и процесс retrieve будет работать плохо (будет попадать много нерелевантных чанков). Первый вариант обычно приемлем, но по сути сводится ко второму: нужен человек, который вручную качественно сортировал бы документы по секциям и пересортировывал при изменениях и добавлениях.
Существуют библиотеки, например, SpaCy, которые могут делать разметку (NER), но без качественной настройки под конкретную тему они работают плохо.
Поэтому мы разработали собственный кластеризатор Clusteroid, который выложили в open source. Он умеет кластеризовать с помощью K-Means или HDBSCAN.
Подпишись 👉🏻 @aigentto 🤖
GitHub
GitHub - alx1379/Clusteroid: Dynamic RAG docs clusterization (meta clusters)
Dynamic RAG docs clusterization (meta clusters). Contribute to alx1379/Clusteroid development by creating an account on GitHub.
🔥8
Как уменьшить цикл обучения AI
В текущих реалиях для обучения/переобучения любой LLM нужны дни/недели и много мощностей, и результат не будет гарантирован: новая LLM может стать лучше, а может хуже.
В Agentic AI добавление новых агентов занимает минуты. Можно внедрить дообучения агентов по своим темам, что по сути является обновлением промта и контекста. То есть можно получить улучшенную версию системы из агентов за минуты, потом ещё улучшенную и т.д.
Если внедрить размножение одинаковых агентов и их эволюцию с отбором сильнейших, crossover и мутацией, то можно запустить Darwin-эволюцию, скорость которой будет очень высока (на каждый новый запрос/задачу система агентов будет становиться лучше).
Лучших можно определять по используемости агентов (=fitness function distance). Чем больше/чаще используется агент, тем он полезнее.
Подпишись 👉🏻 @aigentto 🤖
В текущих реалиях для обучения/переобучения любой LLM нужны дни/недели и много мощностей, и результат не будет гарантирован: новая LLM может стать лучше, а может хуже.
В Agentic AI добавление новых агентов занимает минуты. Можно внедрить дообучения агентов по своим темам, что по сути является обновлением промта и контекста. То есть можно получить улучшенную версию системы из агентов за минуты, потом ещё улучшенную и т.д.
Если внедрить размножение одинаковых агентов и их эволюцию с отбором сильнейших, crossover и мутацией, то можно запустить Darwin-эволюцию, скорость которой будет очень высока (на каждый новый запрос/задачу система агентов будет становиться лучше).
Лучших можно определять по используемости агентов (=fitness function distance). Чем больше/чаще используется агент, тем он полезнее.
Подпишись 👉🏻 @aigentto 🤖
👍2
Почему n8n вам не подойдет?
n8n или Нэйтон и прочие low-code/no-code фреймворки хороши в теории, но когда дело доходит до практики, нужно начинать писать свой код и вставлять его в блоки workflow no-code тулов. Например, чтобы сделать это в Yandex Workflow, у Yandex-разработчика ушло 2 дня 😀 Это не шутка — это правда.
Потом понимаешь, что UI/UX таких тулов очень убогий, а за то время, пока ты выясняешь, почему оно не работает, уже можно было написать много кода (тем более сейчас, когда есть LLM IDE).
И самое главное — все хотят кастомных штук: одному нужны стриминг, другому — чтобы внутри бота был task manager для support, третьему — особая красивая кодировка букв. Всё это нельзя сделать в любых no-code/low-code тулах без кода.
Мне кажется, эра no-code тулов, начавшаяся ещё в 00-х и так и не снискавшая успеха, скоро окончательно закончится, потому что писать код благодаря LLM стало просто и дешево. Но всякие консультанты упорно продают no-code: "зачем вам разработчики, сделай всё сам перетаскиванием кубиков" 😀
Подпишись 👉🏻 @aigentto 🤖
n8n или Нэйтон и прочие low-code/no-code фреймворки хороши в теории, но когда дело доходит до практики, нужно начинать писать свой код и вставлять его в блоки workflow no-code тулов. Например, чтобы сделать это в Yandex Workflow, у Yandex-разработчика ушло 2 дня 😀 Это не шутка — это правда.
Потом понимаешь, что UI/UX таких тулов очень убогий, а за то время, пока ты выясняешь, почему оно не работает, уже можно было написать много кода (тем более сейчас, когда есть LLM IDE).
И самое главное — все хотят кастомных штук: одному нужны стриминг, другому — чтобы внутри бота был task manager для support, третьему — особая красивая кодировка букв. Всё это нельзя сделать в любых no-code/low-code тулах без кода.
Мне кажется, эра no-code тулов, начавшаяся ещё в 00-х и так и не снискавшая успеха, скоро окончательно закончится, потому что писать код благодаря LLM стало просто и дешево. Но всякие консультанты упорно продают no-code: "зачем вам разработчики, сделай всё сам перетаскиванием кубиков" 😀
Подпишись 👉🏻 @aigentto 🤖
❤4👌2
Как потерять пол лимона на fine-tuning?
Одна компания захотела сделать fine-tuning yandexGPT модели, купила мощные видеокарты и нашла подрядчика, который сделал fine-tuning для задачи создания протоколов по встречам (сейчас 100 компаний делают такой SaaS), и получила демо того, как это работает, но выяснилось, что это был "макет", а не реальный fine-tuning.
Компания уже вложилась, уже имеет видеокарты и хочет еще раз сделать fine-tuning 😀 Ищет подрядчика 😀
Такой подход называется: я купил молоток и теперь мне нужно его использовать (я же его уже купил). Не делайте так, решайте задачу, а не пытайтесь найти применение инструменту 🧠
Подпишись 👉🏻 @aigentto 🤖
Одна компания захотела сделать fine-tuning yandexGPT модели, купила мощные видеокарты и нашла подрядчика, который сделал fine-tuning для задачи создания протоколов по встречам (сейчас 100 компаний делают такой SaaS), и получила демо того, как это работает, но выяснилось, что это был "макет", а не реальный fine-tuning.
Компания уже вложилась, уже имеет видеокарты и хочет еще раз сделать fine-tuning 😀 Ищет подрядчика 😀
Такой подход называется: я купил молоток и теперь мне нужно его использовать (я же его уже купил). Не делайте так, решайте задачу, а не пытайтесь найти применение инструменту 🧠
Подпишись 👉🏻 @aigentto 🤖
🤔2
Большинство ИИ-агентов — это приукрашенные конструкции вида ЕСЛИ > ТО
15 лет назад все были в восторге от машинного обучения.
→ Хотите предсказать отток клиентов? Машинное обучение.
→ Клиент, купивший X, также купил Y? Машинное обучение.
→ Прогнозировать продажи на следующую неделю? Опять машинное обучение.
При этом 80% ценности приносили базовые эвристики:
«Если пользователь не входил в систему 14 дней > отправить письмо»
«Если запас опускается ниже порога > сделать повторный заказ»
«Если маржа < X или > X, то остановить кампанию»
Сейчас мы повторяем тот же цикл.
Но теперь — с ИИ-агентами.
ИИ-агенты меняют правила игры.
Но для многих задач они:
❌ создают ненужную сложность
❌ вводят точки отказа
❌ требуют месяцев на разработку
❌ так и не попадают в продакшн
Я очень оптимистично настроен к Agentic AI.
Но я против хайпа, замаскированного под инновации.
Начинайте с:
✔️ Острой бизнес-проблемы
✔️ Очень простого прототипа
✔️ Принципа Парето — 80/20
Подпишись 👉🏻 @aigentto 🤖
15 лет назад все были в восторге от машинного обучения.
→ Хотите предсказать отток клиентов? Машинное обучение.
→ Клиент, купивший X, также купил Y? Машинное обучение.
→ Прогнозировать продажи на следующую неделю? Опять машинное обучение.
При этом 80% ценности приносили базовые эвристики:
«Если пользователь не входил в систему 14 дней > отправить письмо»
«Если запас опускается ниже порога > сделать повторный заказ»
«Если маржа < X или > X, то остановить кампанию»
Сейчас мы повторяем тот же цикл.
Но теперь — с ИИ-агентами.
ИИ-агенты меняют правила игры.
Но для многих задач они:
❌ создают ненужную сложность
❌ вводят точки отказа
❌ требуют месяцев на разработку
❌ так и не попадают в продакшн
Я очень оптимистично настроен к Agentic AI.
Но я против хайпа, замаскированного под инновации.
Начинайте с:
✔️ Острой бизнес-проблемы
✔️ Очень простого прототипа
✔️ Принципа Парето — 80/20
Подпишись 👉🏻 @aigentto 🤖
💯4
Работаем над уровнем 3 и 4
Ранее я писал про будущее Agentic AI. Мы сейчас работаем над уровнями 3 и 4. Скоро будем проводить активное тестирование в полях на двух очень больших компаниях с большими данными и очень сложными workflow. Если подход покажет себя хорошо в этих случаях, то все остальные простые кейсы будут ему тоже по зубам.
Суть здесь в том, чтобы делегировать максимум полномочий ИИ-агентам, иначе зачем мы прикручиваем УМНОГО ИИ-агента и обкладываем его жесткими протоколами и жестким роутингом?! Это то же самое, что нанять кандидата наук и зарегулировать его работу жесткими инструкциями в стиле MacDonalds 🤷♂️
Подпишись 👉🏻 @aigentto 🤖
Ранее я писал про будущее Agentic AI. Мы сейчас работаем над уровнями 3 и 4. Скоро будем проводить активное тестирование в полях на двух очень больших компаниях с большими данными и очень сложными workflow. Если подход покажет себя хорошо в этих случаях, то все остальные простые кейсы будут ему тоже по зубам.
Суть здесь в том, чтобы делегировать максимум полномочий ИИ-агентам, иначе зачем мы прикручиваем УМНОГО ИИ-агента и обкладываем его жесткими протоколами и жестким роутингом?! Это то же самое, что нанять кандидата наук и зарегулировать его работу жесткими инструкциями в стиле MacDonalds 🤷♂️
Подпишись 👉🏻 @aigentto 🤖
Telegram
AIGENTTO
Эволюция ИИ-агентов
Уровень 1
Можно создать одного агента с большим промтом под разные задачи. Будет много глюков и постоянное перетягивание промтов агента для выполнения одной задачи лучше другой.
Уровень 2
Можно разделить на X агентов по чётким задачам…
Уровень 1
Можно создать одного агента с большим промтом под разные задачи. Будет много глюков и постоянное перетягивание промтов агента для выполнения одной задачи лучше другой.
Уровень 2
Можно разделить на X агентов по чётким задачам…
👍3
Молодные безнадежные консерваторы )
Я в ИТ уже более 25 лет, а если считать школьные годы и программирование игр на ZX Spectrum и MS-DOS, то всё 35+ 😀
Я видел много итераций языков, систем, протоколов, фреймворков, команд, и я даже понимаю шутку: Я бы рассказал вам анекдот про UDP, но боюсь, до вас не дойдёт )
У меня была своя нода в FIDONet 2:5005/39, через которую я раздавал траффик своим поинтам, с которыми ходил на поинтовки пить пиво ) Кто-нибудь вообще знает, что такое FIDONet? )
Короче, я давно живу, но меня удивляет, когда некоторые молодые разработчики уже в 25 лет, изучив неплохо Python, очень жёстко делают всё по одной схеме, как их научили. Только linter, только схемы pydantic, только так и никак иначе.
Это особенно сильно их тормозит в области LLM и AI: они используют LLM так топорно, что теряют все преимущества, которые может дать LLM. А некоторые так прямо открыто говорят, что побаиваются LLM использовать в своём коде — ведь оно непредсказуемо.
Когда показываешь им наш новый безшовный вариант работы ИИ-агентов, где нет протокола общения, из-за этого кода совсем чуть-чуть и все решения принимают сами агенты с LLM, они пугаются — они хотят сами описать все схемы данных, использовать жёсткие протоколы и поставить кучу пред- и пост-обработчиков и валидаторов с жестким роутингом в стиле if then )
В ближайшие годы LLMки поменяют все эти подходы, а консерваторы останутся в своем "FIDONet" 🤷
Подпишись 👉🏻 @aigentto 🤖
Я в ИТ уже более 25 лет, а если считать школьные годы и программирование игр на ZX Spectrum и MS-DOS, то всё 35+ 😀
Я видел много итераций языков, систем, протоколов, фреймворков, команд, и я даже понимаю шутку: Я бы рассказал вам анекдот про UDP, но боюсь, до вас не дойдёт )
У меня была своя нода в FIDONet 2:5005/39, через которую я раздавал траффик своим поинтам, с которыми ходил на поинтовки пить пиво ) Кто-нибудь вообще знает, что такое FIDONet? )
Короче, я давно живу, но меня удивляет, когда некоторые молодые разработчики уже в 25 лет, изучив неплохо Python, очень жёстко делают всё по одной схеме, как их научили. Только linter, только схемы pydantic, только так и никак иначе.
Это особенно сильно их тормозит в области LLM и AI: они используют LLM так топорно, что теряют все преимущества, которые может дать LLM. А некоторые так прямо открыто говорят, что побаиваются LLM использовать в своём коде — ведь оно непредсказуемо.
Когда показываешь им наш новый безшовный вариант работы ИИ-агентов, где нет протокола общения, из-за этого кода совсем чуть-чуть и все решения принимают сами агенты с LLM, они пугаются — они хотят сами описать все схемы данных, использовать жёсткие протоколы и поставить кучу пред- и пост-обработчиков и валидаторов с жестким роутингом в стиле if then )
В ближайшие годы LLMки поменяют все эти подходы, а консерваторы останутся в своем "FIDONet" 🤷
Подпишись 👉🏻 @aigentto 🤖
👏4🔥1🤷1
Правило N1 в Agentic AI
В Agentic AI важно декомпозировать функции системы на большое количество агентов. Конечно хочется все запихать в монолит в виде одного агента который умеет все, но мы то знаем к чему это приводит. Поэтому делите Шура делите на агентов и микро-агентов.
И обеспечивайте эффективное общение агентов между собой — ту самую оркестрацию 🎶
Подпишись 👉🏻 @aigentto 🤖
В Agentic AI важно декомпозировать функции системы на большое количество агентов. Конечно хочется все запихать в монолит в виде одного агента который умеет все, но мы то знаем к чему это приводит. Поэтому делите Шура делите на агентов и микро-агентов.
И обеспечивайте эффективное общение агентов между собой — ту самую оркестрацию 🎶
Подпишись 👉🏻 @aigentto 🤖
Оркестрация против роутинга
Роутинг, даже если он гибкий или условный, — это всегда некий жесткий каркас, в котором агенты могут не понять друг друга, и всё может сломаться.
Поэтому лучше использовать оркестрацию: когда есть либо умный оркестратор, который, с помощью LLM, зная, какие есть агенты, MCP, tools, принимает решение, куда направить очередной запрос.
Либо вариант общения агентов без оркестратора, такой как мы сейчас активно тестируем.
Подпишись 👉🏻 @aigentto 🤖
Роутинг, даже если он гибкий или условный, — это всегда некий жесткий каркас, в котором агенты могут не понять друг друга, и всё может сломаться.
Поэтому лучше использовать оркестрацию: когда есть либо умный оркестратор, который, с помощью LLM, зная, какие есть агенты, MCP, tools, принимает решение, куда направить очередной запрос.
Либо вариант общения агентов без оркестратора, такой как мы сейчас активно тестируем.
Подпишись 👉🏻 @aigentto 🤖