Когда AI-агент предлагает кронштейн вместо телевизора

Короче, история. Решил я тут потестировать одного AI-агента для покупок. Вбил простой, на первый взгляд, запрос: «хочу телевизор чтобы повесить на стену»

И что вы думаете? Этот агент проигнорировал главное слово «телевизор» и вцепился в фразу «повесить на стену» и начал мне предлагать… кронштейны 🤦‍♂️ . И вроде бы логично, а с другой стороны - ну нет. Можно же было и дрель с шурупами предложить, чего уж там

Этот забавный сбой - яркий пример того, как RAG-системы могут спотыкаться о буквальную трактовку, упуская суть запроса. Как это исправить? Существует несколько продвинутых техник для настройки RAG-пайплайнов, рассмотрим некоторые из них

⭐️ Подход 1: Query Expansion
Вместо того чтобы слепо следовать запросу пользователя, система с Query Expansion генерирует несколько его вариаций, чтобы лучше понять контекст. То есть, она бы не просто искала «повесить» и «стена», а додумалась бы до запросов вроде: «телевизоры с настенным креплением» или «купить телевизор для монтажа на стену». Так основной объект телевизор остался бы в фокусе.

⭐️ Подход 2: Multi-Step RAG
Multi-step RAG - это когда система не пытается решить все в один заход, а бьет задачу на этапы. В моем случае это выглядело бы так:

⏩Шаг 1: Выделить главное: объект («телевизор») и действие («повесить на стену»)
⏩Шаг 2: Сначала найти «телевизоры». И только их
⏩Шаг 3: Из найденного отфильтровать те, что подходят под «повесить на стену»

⭐️ Подход 3: Метаданные как фильтр
Каждый товар в базе можно (и нужно!) обвешать тегами: категория, тип, цена и т.д. В контексте RAG-пайплайна важны все детали: от диагонали экрана до адреса склада

Если каждый товар в базе данных магазина имеет мета-теги вроде  category: "television"  или  type: "wall_mount" , система сработает лучше. Мой запрос «хочу телевизор» активировал бы фильтр по категории  television , и даже слова «повесить на стену» не смогли бы сбить его с толку и заставить искать аксессуары

⭐️ Подход 4: Агенты-критики и Chain of Debate
Парадигма multi-agent debate предполагает, что над задачей работает не один, а несколько специализированных AI-агентов, которые ведут «дебаты» для поиска лучшего решения

Представьте их диалог:
〰️ Агент «Анализатор запроса»: «Пользователь хочет что-то повесить на стену. Наверное, ему нужен кронштейн».
〰️ Агент «Эксперт по товарам»: «Подожди, основной объект в запросе - “телевизор”. Это главный товар. Фраза “повесить на стену” - это характеристика, а не самостоятельный запрос. Предлагать аксессуар, не убедившись в наличии телевизора, - это плохой клиентский опыт».
〰️ Агент «Модератор»: «Решено. Ищем телевизоры, которые можно повесить на стену».


Индустрия AI-агентов развивается стремительно, и сама возможность создавать «агентов для покупок» - это уже большое достижение 💪 . Однако, как показывает этот случай, RAG-архитектуры нуждаются в тонкой настройке.

Stay tuned - в будущих постах обязательно разберем каждый из этих подходов подробнее

P.S. ранее уже разбирал, где можно улучшить ваш RAG-Pipeline

Положить LLM в карман: стоит ли выносить языковую модель из облака?

В какой-то момент гонка за облачными мощностями начинает утомлять. Ты привыкаешь, что для любой серьезной задачи с LLM нужен API-ключ и хороший бюджет. Но в IT, как известно, все циклично, и вот снова набирает силу тренд на on-device AI - возвращение вычислений с небес на землю, прямо на наши устройства

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

Для меня последней каплей стал пост Иэна Баллантайна (Linkedin), где он заставил свежую Gemma 3 270M от Google летать на Raspberry Pi 5. Его цифры - около 30-32 токенов в секунду на голом CPU - звучали слишком хорошо, чтобы быть правдой (ниже будет видео от автора)

Цитата автора:

как быстро работает Gemma 3 270M "из коробки" на Raspberry Pi 5? Около 30 токенов/сек на CPU для квантизованной модели Q4_0 при использовании Ollama. Я также попробовал Llama.cpp и получил около 32 токенов/сек

Увидев такие цифры, я окончательно решился повторить его эксперимент

Мой тестовый стенд
Конечно, в мечтах - домашний мини-кластер на четырех GPU, но начнем с малого. Мой сетап для эксперимента:

Устройство: Orange Pi 5 Pro с 16 ГБ оперативной памяти (оно по некоторым параметрам даже превосходит то, что было у Иэна)

Кандидаты на запуск:
✨ Frida - компактная русскоязычная модель от команды ai-forever, удобная для экспериментов за счёт небольшого размера (<300 M параметров) и открытых QAT-чекпоинтов
✨ Gemma 3 270M - свежая модель от Google, оптимизированная для энергоэффективности и быстрой тонкой настройки

Главный вопрос: какая в этом мотивация?
Прежде чем погружаться в технические дебри, я решил посчитать, имеет ли эта затея экономический смысл

Окупаемость железа
- Аренда схожего по характеристикам облачного CPU-сервера – ≈ 5 300 ₽/мес
- Покупка Orange Pi 5 Pro – ≈ 12 000 ₽
- Разделив, получаем ≈ 2.3 месяца до полной окупаемости оборудования

Дополнительные затраты
Конечно, в расчёт не вошла стоимость моего времени на настройку. Но для энтузиаста это скорее удовольствие, а потребление энергии устройством (≈ 6–10 Вт под нагрузкой) сравнимо с ежемесячным счетом за лампочку, в то время как облачные серверы обходятся в сотни рублей за час работы.
📌 Вывод: локальный деплой выгоден при регулярных нагрузках; для редких задач облако остаётся привлекательным

Экономия на API-токенах
А вот здесь все не так однозначно. Если вам нужно лишь изредка обращаться к модели, использование API через облако может быть очень дешевым. Например, для редких задач вызовы самой доступной русскоязычной модели обошлись бы примерно в 0,02 ₽ за 1 000 000 токенов. Очевидно, что покупать отдельное устройство из-за такой низкой цены токена бессмысленно.
📌 Вывод: Локальный деплой выгоден, если вы заменяете им постоянно работающий облачный сервер, а не редкие API-вызовы

Зачем это нужно в глобальном смысле?
Экономия - это приятно, но потенциал локальных моделей гораздо шире. Вы думаете, успехи Китая в роботизации - это шутки? Локальные LLM играют в этом ключевую роль. Робот на производстве или дрон-курьер не могут зависеть от стабильности интернет-соединения с дата-центром. Им нужна автономия

Перенос AI на устройства дает:
🔵Приватность: Данные обрабатываются локально и не утекают на сторонние серверы
🔵Низкую задержку: Отклик модели происходит мгновенно, что критически важно для систем реального времени
🔵Надежность: Устройство работает даже без подключения к сети

Что дальше?
Я пока только приступил к тестам и в ближайших планах развернуть Frida и Gemma 3 270m на своем Orange Pi. Очень интересно, какие результаты удастся получить и насколько они будут близки к показателям на Raspberry Pi

#hardware

Спонсор вайба на выходных - Илон Маск, а с меня - свежий лайфхак для vibe-кодинга

Начну сразу с главного: два дня тестирую новую Grok Code Fast 1 (xAI), которую сейчас бесплатно раздают в Cursor (аж до 2 сентября, вы тоже успеете потестировать), но все таки, пока что личный фаворит - это Claude 4 Sonnet

Grok Code Fast 1 генерирует код с какой-то нечеловеческой скоростью (авторы заявляют 160 tokens per second). Я с ним за час набросал ядро сложного мультимодального RAG-поиска. А потом пришло время все это собирать воедино с основным сервисом. И пошли проблемы. Ассистент, пытаясь исправить одну ошибку, создавал три новых. Думаю эта ситуация знакома многим

И вот мой лайфхак, который спасает 90% времени и нервов - это тесты с подробными логами. Это ваш единственный объективный критерий того, что все работает как надо

Этот подход можно разбить на две части

Допустим, мы только что собрали мультимодальный RAG-поиск. Мой промпт будет выглядеть так (обычно пишу на английском - субъективно работает лучше и дешевле):

🟡Пишем тесты:

Here is the python module with multi-modal RAG logic [code]. Your job is write an extensive tests for it using pytest. I need at least 20 tests covering huge bunch of cases: from file uploads to API responses and edge cases like empty inputs and hard cases with different input combinations.

Обычно в момент написания все тесты проходят без проблем, но это только пока мы не насоздавали еще десятки зависимостей

🟡А если зависимости все ломают, то дебажим при помощи тестов:

Okay, look. Here is the output of the tests we wrote before. [вставляю лог с ошибками]. 4 / 20 tests failed. Your changes broke the critical functionality. Your one and only goal right now is to fix the code so that all 20 tests pass again. start fixing all failed tests.

И это отлично работает! Особенно когда приходится переключаться между чатами с потерей контекста

Что касается моих впечатлений от Grok Code Fast 1 - модель быстрая, но сыровата, хотя метрики на SWE bench могут впечатлить. Для большинства практических задач связка Claude 4 Sonnet с описанной выше методологией пока остается непревзойденной. Я потратил час на написание фичи с Grok, а потом еще 30 минут дебажил результат с помощью Claude и тестов..

Всем вайбовых выходных!

💃 #vibe_coding@ml_maxim

🔍 Что скрывается под капотом Perplexity?

Когда AI отказывается выполнить задачу, ссылаясь на "лимиты ресурсов", возникает вопрос: а что это за лимиты? Со мной случился как раз такой кейс.

Я решил выяснить, что происходит внутри Perplexity, когда он выполняет код. Попросил AI проанализировать собственные логи и окружение. И он буквально сам рассказал: "Я работаю в Docker-контейнере на Linux 6.1, у меня 2 CPU и 1GB RAM..." и далее выдал полную базу, вплоть до локации своего сервера (кстати, США, штат Орегон)

Perplexity использует E2B Sandbox - специализированную платформу для AI-агентов. Каждый ваш запрос с кодом запускается в контейнере.

🔵 Архитектура: FastAPI ↔ WebSocket ↔ Jupyter Kernel
🔵 Оптимизация: uvloop + orjson + httptools

Это объясняет, почему AI иногда "отказывается" - не из-за технических лимитов, а из-за бизнес-логики системы. Ведь критически важно быстро отдавать пользователю результат - это основной приоритет таких решений

GitHub Copilot, Replit, CodeSandbox - все используют похожие решения

Зная архитектуру подобных решений, можно:
🔜 Правильно использовать контекст
🔜 Оптимизировать запросы под систему (и манипулировать системой)
🔜 Понимать реальные ограничения и бизнес-логику

Понимание внутреннего устройства AI-систем становится критически важным навыком. Это не просто любопытство - это практический инструмент для более эффективной работы

📖 Полное исследование на Habr

Разбор решения Yandex Cup

Прошел Yandex Cup, где в треке ML я выбрал задачу STEM problem Q&A для VLM моделей (это когда надо решать задачи по математике и физике с листочка - но только в нашем случае, при помощи VLM)

Самое время подвести черту и поделиться решением 📃

Сразу отмечу: радует, что агенты стали нормой. Комьюнити созрело, орги не банят за LLM-кодинг. Кажется, все приняли как данность, что без этого теперь никуда.

Мой технический стек

В итоге я вышел на такое решение:

Ядро: Qwen3-VL-8B-Instruct + 4-bit квантование
Методы: Chain of Thought + Prompt Routing
Почему так: Большие модели лучше маленьких - это факт. Я пробовал собирать ансамбли из мелких моделей, но они никак не могли приблизиться к одной большой. Time Limit в 1 час сильно ограничивал: на полноценную Thinking-модель времени инференса мне просто не хватило (квантованные версии не попробовал). До finetune версий моделей тоже не дошел


Что было больно (и интересно)

🔵Недетерминированность. На графике динамики лидеров видно, как участников штормило. Один из вариантов решения - поставить высокую температуру и устроить Voting одной и той же версии модели. Понятно что такое решение невоспроизводимо. Даже с температурой 0 метрика гуляла. Ты запускаешь топовое решение второй раз, и оно падает в рейтинге

Инженерные вызовы и хаки

🔵Контейнеризация. Часть успеха - корректно развернуть модель в докере. Это был отдельный инженерный вызов

🔵Железо. Хорошо бы иметь домашний Linux GPU-кластер (ну или брать его в аренду). Это единственный способ сделать локальную валидацию быстрой и приближенной к проду.

Моя главная ошибка:

Я собрал неверный сет для локальной валидации. Использовал ScienceQA, Geometry3k и MathVista, но поздно понял, что у меня нет корреляции Local / Public Leaderboard. Был момент, когда из-за бага давали 8 сабмитов в день - идеальный шанс подобрать val data, но я его упустил. В итоге локально метрика росла, а на лидерборде - нет.

Классический совет себе на будущее:

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

Завтра расскажу про свой подход к vibe-competiting - как решать задачи с помощью co-solver’а и не сойти с ума

P.S. Интересно, кто-то из финалистов уже рассказал о своем решении? Если знаете - скидывайте ссылки в комментарии