Если ваш ИИ-сгенерированный контент пессимизируется поисковиками, то проверьте его на ватермарки. ИИ-сгенерированный контент лучше чистить 🧹

Например, ИИ от OpenAI оставляет скрытые ловушки (ватермарки) в тексте - o4-mini и o3 прячут коды неразрывного пробела в формате Unicode 🥷

Они не видны в большинстве редакторов, но их можно найти, например таким скриптом.

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

Подкаст на основе последней статьи по теме "Как сделать RAG систему для своей компании". Для тех кому проще послушать, чем читать.

Сделано на основе https://notebooklm.google.com, очень удобно. Я, когда большую статью лень читать, делаю такой подкаст и слушаю, когда бегаю. Любая тема, озвученная в ролях, намного легче заходит, потом всегда можно посмотреть в статье точечно то, что заинтересовало. Рекомендую ➕➕➕

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

Ограничения инфраструктуры 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/ИИ-Асистента без кода 🔥

Делаем генератор постов для канала📖, поиск рейсов ✈️ и бронирование отелей через Yandex Travel API 🛎

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

В создании ассистентов и 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 🤖

Тонкая настройка работы RAG-системы

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

🐳 Нужно поиграть с размером и overlap (взаимным перекрытием чанков)

🔪 Если не помогает, нужно изменить нарезку чанков: вместо отрезания по чёткой длине (300, 1000, 2000 символов) можно начать резать, учитывая целые слова и предложения

📦 В выборке нужно поиграть с количеством выбранных чанков — лишняя информация часто заставляет галлюцинировать LLM

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

Всё это занимает много времени в цикле:
👉 поменял
👉 переиндексировал векторную БД
👉 прогнал тестовые вопросы
👉 повтор

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

Я называю это ЧАНКИНГ 😁

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

Жесткие критерии тестирования RAG-систем или почему вопросы имеют значение?

Так как LLM — очень гибкий инструмент, при создании RAG-систем и ИИ-агентов всегда будут кейсы, когда оно отвечает/понимает немного по-разному. Особенно это касается сложных запросов, где много предположений и недосказанностей.

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

Пример плохих вопросов:
- кто у нас зам згд
- дай контакты делле
- кто у нас самый главный

LLM, конечно, попробует догадаться, что «згд» в нашем контексте — возможно заместитель генерального директора... а «самый главный» — это, наверное, генеральный или председатель? А «делле» — это, наверное, фамилия?

Но, во-первых, может и не догадаться, а во-вторых, если догадается, то, учитывая сложную семантику, оно может начать догадываться дальше, и в ответ попадут неточные или совсем неверные данные.

❕Нужно помнить, что всё, что делает LLM — это догадывается, какой следующий токен. Поэтому чем точнее заданное направление, тем точнее ответ и меньше галлюцинаций.

👉 Либо задавайте развернутые вопросы, на которые точно есть ответ в документах.

💡 Либо вносите в свои документы свои же термины. По сути, можно просто добавить к документам файл термины.txt и там разжевывать все места, где модель глючит. Таким образом можно не переделывать оригинальные доки.

Подпишись 👉🏻 @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 🤖

Новый обязательный вопрос на интервью разработчиков

Сейчас ведём найм backend-разработчиков, и на screening-интервью я добавил новый обязательный вопрос: А как вы используете LLM или IDE с LLM для написания кода?

Отвечать на такой вопрос — почти не использую, всё пишу сам — это примерно как отвечать 100 лет назад, что автомобиль пока не использую, лошадь надёжнее и понятнее.

LLM и всякие Cursor, Anthropic уже несколько лет с нами, вы просто обязаны их использовать для увеличения своей производительности 🚀

👉 Первый уровень — это обычно просто web-чат с ChatGPT по конкретному коду

👉 Второй уровень — это IDE с настройкой system prompt под свой проект (чтобы оно не тупило и не делало плохие штуки)

👉 Третий уровень — это подключение всяких JIRA, Wiki через MCP, чтобы бизнес-документация сама бралась в LLM, и задачки в JIRA сами двигались по workflow

Второй и третий уровень требуют усилий по настройке и тюнингу под ваши проекты, но если вы этого не сделаете, то и в XXI веке всё ещё будете использовать надёжную, хорошую, проверенную веками лошадь 🐴

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