Max: AI, Engineering and Startups

Ликбез про RAG. ч.2. Фундаментальные ошибки. За последние 3 года я пообщался с десятком+ команд из разных компаний, работающих над приложениями на основе RAG.  Две самые частые ошибки, которые я встречал:  - плохая подготовка данных - garbage-in > garbage-out, - отсутствие evaluation (оценки качества) - не возможно улучшать то, что не измеряешь. Разумеется, существует множество других проблем, но это фундамент для всей системы, без которого остальные решения теряют значимость. И самое нелепое, что обе проблемы очевидны с первого взгляда, но из-за сложности их решения, менеджеры зачастую игнорируют их до последнего. 1️⃣  Плохая подготовка данных - самая частая и известная ошибка любых DS/ML/DL проектов.  Я заметил, что она особенно актуальна для Gen AI проектов, потому что люди, работающие над такими проектами часто не имеют профильного образования или опыта работы с DS проектами. Некоторые инженеры всерьез считают, что если они сделали pip install langchain, то теперь они AI Engineer. Уже 3 года веду репо с подборкой бесплатных материалов по AI разработке, чтобы закрыть эту проблему в своих командах: GH repo. Что делать с проблемой плохих данных? Ответ очевиден - чистить.  Самые универсальные советы: - удалять старые и нерелевантные данные, дубликаты, пустые документы, - проверять, что pdf, картинки, диаграммы, Excel, Word, attachements правильно обрабатываются, - эффективно использовать мета-данные и структуру в данных, - вычистить ошибки (фактологические, грамматические), - предпочтительно иметь все тексты на одном языке, - нормализовать онтологию - особенно, актуально для внутрипроектной документации. Когда пишешь это, кажется, что все это какая-то базовая база, но вы не поверите как много людей не задумываются, что не надо игнорировать Excel, прикрепленный к Confluence странице или что невозможно делать нормальный векторный поиск по базе, где 30% документов - это заголовок без дополнительного текста. После того как данные вычищены очевидный следующий шаг - разобраться, как правильно структурировать и предобрабатывать данные именно для вашего алгоритма поиска.  2️⃣ С evaluation все немного сложнее. Зачем вообще мерить качество системы? С точки зрения бизнеса - без оценки качества не понятно решает ли система поставленную задачу и приносит ли она вообще пользу. С точки зрения разработчика - не возможно улучшать то, что ты не измеряешь. Существует 3 типа метрик: - бизнесовые (какую пользу в деньгах приносит RAG приложение), - продуктовые (DAU, MAU, NPS, Session Length, actions or events и тд), - качественные (точность, релевантность, полнота,  MRR, …) Бизнес метрики мерить напрямую, как правило, сложно, поэтому используются продуктовые прокси-метрики. Например, это может быть количество закрытых задач и среднее время, сэкономленное на задачу. Если все честно померить, то внезапно может оказаться, что разработка и внедрение AI приложения не оправдывает ожиданий. Для качественных метрик можно выделить 4 дополнительных подмножества: - оценка качества собранных данных (не популярно, а зря), - оценка поиска, - оценка генерации, - оценка всей системы целиком - то есть качества ответов. Последний вариант самый простой и можно начинать с него, но проблема в том, что через E2E оценку очень сложно управлять качеством отдельных этапов. Тем не менее начинать лучше всего именно с него - максимум ценности за минимум затрат. Есть несколько способов померить качество ответов: - Автоматические метрики (Bertscore, BLEURT, ROGE, и тд). На практике не применяются из-за крайне низкого качества оценки, - Бинарный или фактологический датасет с закрытыми вопросами и однозначными ответами поверх которого можно посчитать F1 и другие классические DS-метрики, - Human eval - человек вручную читает ответы и оценивает качество. Обычно самый точный из способов, но самый дорогой. Его не возможно прогонять eval на каждое улучшение, - LLM as-a-judge и его разновидности, - Автоматическая верификация результата. Отлично работает для задач программирования или математики, где можно автоматически проверить полученный результат. Как правило, нужен датасет эталонных вопросов-ответов (validation и test датасеты). Лучше всего составлять его частично вручную частично с использованием AI, но под очень пристальным контролем с валидацией каждой пары. Самым частым способом оценки является LLM as-a-judge, потому что он дешевый в реализации, его можно прогонять вместе с тестами на каждое изменение и он относительно универсальный. Но как всегда есть нюанс. Нужно убедиться, что LLM дает такую же оценку качества системы как и человек. Для этого делают meta evaluation, когда человек делает оценку качества вручную и затем сравнивают с подходом LLM-as-a-judge.  Есть много библиотек для evaluation, из того что я пробовал: RAGAS, DeepEval, TrueLens. Но в итоге написать собственную обвязку оказалось эффективнее. Для менеджеров важным инсайтом будет, что пропорция времязатрат на разработку и eval, такая же как у разработки и тестирования. В среднем “по больнице” 3 к 1. Но если вы делаете высокорисковое приложение, на тестирование которого уходит почти столько же времени сколько на разработку, то и для evaluation приложения в этом домене нужно ожидать сопоставимое количество трудозатрат. @max_about_ai

Про Fable 5 Я успел протестировать Fable 5 до его блокировки, но не успел закончить тесты. Дождаться разблокировки не удалось, так что поделюсь тем, что есть: 1⃣ Fable гораздо лаконичнее других моделей. Ответы именно лаконичнее, а не короче, то есть плотность информации выше, чем у других моделей. Мне это очень нравится, не люблю воду в текстах. 2⃣ Ответы Fable на прямолинейные замечания могут иметь яркую эмоциональную окраску. Если бы это был человек, я бы решил, что он на меня разозлился или обиделся. Это вызывает странные ощущения, я не сторонник антропоморфизации LLM. Но главное, что я не успел протестировать до конца - как это влияет на качество ответов моделей. У людей негативные эмоции, часто приводят к снижению качества взаимодействия, обладает ли Fable этим свойством или она сохраняет объективность? Вот цитата Fabble: Если и это не “главное” - окей, тогда сформулируй сам. Я свои версии исчерпал, и угадайка без обратной связи мне неинтересна. 3⃣ Fable смогла понять что я ее тестирую в ситуации, где я этого абсолютно не ожидал. Я проверял ее способности в принятии решений в условиях нехватки информации, и она быстро «раскусила» меня. Можно только догадываться, как это может повлиять на safety тесты. игра шла про другое: что я делаю под давлением без содержания. И текущий вопрос - её продолжение: теперь проверка, могу ли я моделировать тебя, а не только спорить с пустым стулом. 4⃣ На разработческих задачах протестировать не успел. Но все кто успел - хвалили. Хотя x2 к цене API по сравнению с опусом, вероятно, все-таки не оправданно. Если не будет входить в подписку, то сам я доплачивать вряд ли буду. 5⃣ Добавлю еще одну ложку дегтя - как и другие модели Антропик, Fable чаще чем GPT-5.* оперировал устаревшими данными и на их основе уверенно делал неверные выводы в моих тестах. Там где в ChatGPT достаточно было задать вопрос напрямую, в Claude нужно пробрасывать контекст или промптить так чтобы Claude не забыл сходить в интернет проверить актуальную информацию. @max_about_ai

Мне интересно читать каналы, где автор не пересказывает позавчерашней Твиттер или презентации БигТехов, а делится своими мыслями по интересной мне теме. Когда 6 лет назад мне пришлось начать совмещать роль Technical Product Manager с моей основной ролью, я искал что бы почитать по новой для меня роли и нашел канал Ани Подображных. Сегодня хочу его порекомендовать, потому что до сих пор читаю.  Мне нравится, что посты про product management чередуются с постами про персональную эффективность, личными историями, а также всякими полезностями типа вакансий. В общем, мой личный рекомендасьон. @max_about_ai

AI ликбез: RAG (Retrieval Augmented Generation) ч.1 Решил, что RAG как концепция настолько важен для современных AI приложений, что несмотря на широкую общеизвестность, все равно заслуживает отдельной серии постов в канале. 1️⃣ RAG (Retrieval Augmented Generation) - это подход, когда перед генерацией LLM ответа, приложение ищет релевантую информацию в внешних данных и добавляет ее в контекст вопроса, делая генерацию ответа аргументированной. Схематично: RAG = поиск релевантной информации > создание контекста > генерация ответа LLM по контексту Главная идея: не нужно учить модель всем вашим данным, нужно научить систему находить правильный контекст для модели. Скорее всего вы уже пользуетесь приложениями, использующими RAG в том или ином виде, потому что это базовый кирпичик поверх которого строится работа AI ассистентов, копайлотов или агентов. 2️⃣ RAG призван решить следующие проблемы: - LLM не знает ваши внутренние документы - LLM может галлюцинировать и нужна верифицируемость ответов (например, ссылки на источники) - Знания LLM устаревают В качестве альтернативы RAG рассматривают prompt engineering или fine-tuning. Но в-первом случае, невозможно добавить много документов и знаний в один промпт из-за ограничений размера контекстного окна и высокой стоимости токенов, а следовательно вопросов-ответов. А во-втором, стоимость дообучения модели и необходимость постоянно добавлять данные делают его практически непригодным для часто изменяющихся данных. 3️⃣ Базовым подходом к поиску в RAG является векторный поиск. Он не всегда лучший, но самый популярный. Часто базовый пайплайн называют Naive RAG и он состоит из двух этапов: Этап 1. Подготовка данных: Документы -> Chunking (разбиение на части) -> Embedding generation (векторизация) -> Vector DB Этап 2. Рантайм: Вопрос -> Retriever (векторный поиск в базе данных) -> Reranker (сортировка по наибольшей релевантности) -> LLM -> Ответ и источники В научных работах и на синтетических бэнчмарках Naive RAG показывает хорошие результаты, но на практике существует бесконечное количество подводных камней и пограничных ситуаций. Если полученная система на основе Naive RAG показывает 90% точности на репрезентативной выборки - это считается очень хорошим результатом, но такая точность не достаточна для большинства бизнес-сценариев. Поэтому в большинстве систем Naive RAG либо заменяется либо дополняется более продвинутыми техниками. Про разные архитектуры, оценку качества, проблемы и путь от прототипа до продакшена, я расскажу в следующих частях. @max_about_ai

Про AI research На этой недели моя AI лаба опубликовала первые научные статьи по AI engineering на arXiv (объяснимость ответов в graph RAG и синтетический эвал для LLM приложений). Команда - большие молодцы, потому что они справились, несмотря на огромное количество препятствий на нашем пути. Не буду пересказывать статьи, поделюсь лишь нескольким практическими выводами, которые я сделал по ходу исследований: 1⃣ Graph RAG - как концепт очень круто, но на деле выходит долго и дорого, а прирост в качестве ответов не столь значим и даже не всегда есть. 2⃣ Еxplainability у ответов на базе Graph RAG действительно выше, но на практике использовать это из-за скорости и цены почти не возможно. 3⃣ Сложность задачи “сделать качественный evaluation LLM приложения“ сопоставима с сложностью разработки такого приложения (по крайней мере одного порядка). 4⃣ Все еще мало исследований по оценке качества ответов LLM для языков за пределами двадцатки самых популярных. Если вы носитель такого языка и хотите сделать AI research - это отличная возможность. 5⃣ Скорость исследований в AI настолько высока, что темы устаревают за 3-6 месяцев. В октябре мы начали заниматься изучением повышения эффективности Context Engineering для AI SWE инструментов. За полгода часть наших гипотез уже успели зарелизиться в Claude Code или Codex, а до окончания работы нам еще 2-3 месяца. И в силу разного рода факторов у меня нет возможности ее ускорить. 6⃣ Доступ к современным исследовательским инструментам превратился за два года из преимущества в жизненную необходимость. @max_about_ai

Провел две недели отпуска в роад-трипе. Как писал выше, поиск use cases для применения AI не проще, чем освоение самих инструментов, поэтому решил поделиться парочкой сценариев использования, чем сам пользовался в путешествие. 1️⃣ Перевод фото меню, объяснение состава и выбор подходящих блюд из меню с помощью ChatGPT. Перевод меню в классических переводчиках обычно работает плохо и не объясняет что ожидать от блюда. Особенно помогает, если есть какие-то ограничения или выраженные предпочтения в еде. 2️⃣ Разборки с парковкой, платными дорогами и экологическими зонами. Когда за поездку сменяешь несколько стран можно запутаться в особенностях правил парковки и тут ChatGPT очень выручает. Можно сфоткать знак или автомат оплаты и понять можно ли здесь парковаться сейчас и сколько это будет стоить. Также встречаются довольно специфические дороги, где оплачивать дорогу надо не на посту оплаты и не заранее (виньетка), а, внезапно, онлайн. Хз, сколько времени ушло бы разобраться что значили бы те знаки без ChatGPT. 3️⃣ Составление маршрута поездки на авто. Это актуально если цель не просто доехать из пункта А в пункт Б, а хочется новых впечатлений и интересностей по дороги или есть какие-то другие факторы. Впрочем, здесь полностью полагаться на AI не стоит и есть смысл изучать вопрос также по картам. Кстати, можно попросить преобразовать построенный маршрут в Google ссылку со всеми точками. 4️⃣ Поиск решений в нештатных ситуациях - всем что угодно от оплаты штрафа до разборок со страховой компании в случае срочной стоматологической помощи. 5️⃣ Помощь с выбором жилья. Подбор и бронирование размещений AI агентами до сих пор нормально не работает (по моим критериям). Но вот кинуть ссылки на 3-5 уже самостоятельно отобранных варианта и попросить совета с выбором бывает очень полезно. Часто всплывают подводные камни и нюансы, о которых сам не подумал бы - например, криминальный район или плохая транспортная доступность. @max_about_ai

Банально, но факт - сейчас открыто окно беспрецедентных возможностей. Как долго оно будет открыто и что наступит после - я не знаю, но точно знаю, что если делать что-то свое, то сейчас отличное время пробовать. Поэтому моя жена решила открыть свой мини-стартап на международный рынок. Хочет бутсрапить небольшие SaaS приложения. С вайб-кодингом это стало сильно проще, тем более, что у нее айтишный бэкграунд и образование. Осталось только научиться продавать. Я предлагал с ChatGPT разобраться, но как-то не пошло - слишком много непубличных лайфхаков в маркетинге, которые никто не хочет шарить публично. На Coursera тоже ничего толкого не нашли. Так что с середины апреля она пойдет на платные курсы по маркетингу. Слышал положительные отзывы от друзей о других курсах Глеба Кудрявцева, надеюсь, и эти не будут исключением. Посмотрим, что из этого выйдет, но я твердо убежден, что успех - это функция от числа попыток, так что рад, что она решилась попробовать. PS: буду иногда делиться её успехами, пока она не завела свой ТГ канал. @max_about_ai

Про универсальных AI агентов Последний месяц эксперементирую с Claude Cowork, OpenClaw и Manus. Мои краткие выводы: 0️⃣ Если у вас FOMO, что все вокруг в 10 раз эффективнее благодаря OpenClaw и другим AI агентам, то можете перестать нервничать - технологии все еще далеки от совершенства. Пока хайпа все еще больше чем пользы. Значит ли это, что не надо их пробовать или использовать? Нет! Потому что уже сейчас можно делегировать отдельные задачи, а в какой-то момент рост станет эскпоненциальным и на нем можно будет хорошо вырастить свою карьеру или бизнес. 1⃣ Самый зрелый из протестировнных продуктов - Claude Cowork. Он может управлять Chrome и десктопом. А запускать его на десктопе можно с мобилки при помощи функции Dispatch. У него есть библиотека скиллов, коннекторов и плагинов. Работа организуется в проекты. Я прикрутил его в папку c Obsidian и перевел часть своих заметок в markdown, но большой пользы пока не ощутил - work in progress. 2⃣ Если нужна максимальная гибкость, то есть смысл выбирать между OpenClaw и его open-source аналогами (NanoClaw, PicoClaw, и тд). Я не настолько богатый чтобы покупать выделенную MacStudio, но при этом хотел сохранить максимальный контроль, поэтому поставил OpenClaw на локальную виртуалку (UTM + Debian). Лайфхак - можно попросить Claude Cowork настроить вам OpenClaw в виртуалке. Он прилично сэкономил мне времени. Хотя Warp, вероятно, был бы еще эффективнее. Еще к OpenClaw и ее скилам у меня вопросы по безопасности. Особенно актуальные на фоне недавних новостей про supply-chain атаку на библиотеку LiteLLM, когда злоумышленники добавили фишинговый код в open-source библиотеку и отправляли конфиденциальные данные (карточки, пароли,…) себе на сервер. 3⃣ В каких случаях может быть полезен именно Manus при наличии альтернатив я так и не понял. Все кредиты из 20 долларовой подписки он сожрал за 5-6 относительно простых запросов. А качество работы оказалось - "ну такое". Не рекомендую. 4⃣ Ок, поставили Claude Cowork или OpenClaw. Что дальше? Вот тут начинается самое интересное. Почти все мои AI use cases уже и так либо закрываются Codex / Antigravity / Warp, либо закрываются extended thinking в ChatGPT, либо все еще не пригодны для автоматизации по тем или иным причинам. Впрочем, возможно, дело во мне и моей низкой степени доверия подобным инструментам. Если у вас есть интересные сценарии использования универсальных AI агентов - поделитесь, пожалуйста, в комментариях. По ощущениям, сейчас сложность не в том как поставить или настроить AI инструменты, а в том в каких сценариях их использовать. Про свои сценарии я напишу в одном из следующих постов. @max_about_ai

Поучаствовал в подкасте про Product Engineering. Вместе с Юрой Агеевым, автором подкаста Make Sense, поговорили про будущее ролей в разработке, кто такие Product Engineer, как ими стать если вы уже разработчик или продакт менеджер. Не обошли стороной вайб-кодинг и AI для личной эффективности. Из разговора мне больше всего запомнилась история Юры про его опыт с AI агентами. У него кастомная команда агентов поверх Claude Code и каждую ночь они проводят ретро пока он спит. Так вот целую неделю подряд они называли его ботлнеком и жаловались друг-другу на него. Послушать целиком можно в Я.Музыке, Apple, YouTube. PS: я впервые участвовал в подкасте - новый интересный опыт для меня. Буду рад вашему фидбеку. @max_about_ai

Наконец дошли руки посмотреть материалы курса Stanford “CS146S: The Modern Software Developer”. Видеозаписей, к сожалению, в открытом доступе нет, но есть презентации и отличная подборка материалов для чтения и просмотра. Мне особенно понравилась презентация про Code Review. Навык, который всегда был важным, но c 2025 года стал еще важнее. Если собеседуете кандидатов - обязательно добавляйте задачки на код ревью, а если сами собеседуетесь - будьте готовы к ним. Еще понравился шаблон дизайн-документа. Он избыточен, но позволит не забыть что-то важное, а неважное для текущего проекта можно просто выкинуть. В общем, если еще не видели этот курс и ссылки из его подборки, то полезно ознакомиться. @max_about_ai