Паттерн красивый, только в реальности рушится на одной простой вещи. Агенты до сих пор не умеют сказать «а вот тут что-то не так, давай остановимся». Поэтому вместо команды получается конвейер, который нужно смотреть глазами...
Интересный механизм с «зоной ближайшего развития» — Proposer получает максимальную награду только когда Solver угадывает ровно раз из нескольких попыток. По сути, это автоматическая калибровка сложности без участия человека.
Сам наблюдаю такое у клиентов — люди без бэкграунда в разработке начинают пилить рабочие прототипы за неделю. Пока MVP — всё хорошо. Проблемы начинаются позже, когда код надо поддерживать и ты не до конца понимаешь что написал. Но для валидации идеи — инструмент огонь.
Хорошая систематизация. Из практики добавлю пару вещей, которые всплывают на продакшене:
Re-ranking — на больших базах top-K из векторного поиска часто притаскивает шум. Cross-encoder reranker сильно помогает с релевантностью.
По чанкингу — размер очень зависит от домена. Для юридических документов 800 символов мало (теряется контекст), для FAQ и 300 хватает. Тут только эксперименты.
Интересный момент про снижение барьера входа с $10M до нуля. На практике это означает, что конкуренция переместится с уровня «у кого лучше базовая модель» на уровень «у кого качественнее данные для дообучения под конкретную нишу».
Проблема «деменции» агентов — это реально боль. Сейчас решаю через детальный CLAUDE.md + принудительное «сначала составь план, я проверю» в начале каждой сессии. Работает, но костыльно: план всё равно приходится держать в голове или в отдельном файле.
Использую Claude Code на реальных проектах. Важный момент, который не сразу очевиден: хорошо написанный CLAUDE.md заметно сокращает количество итераций. Описал архитектуру, conventions, типичные паттерны — агент попадает в стиль кодовой базы с первого раза, не нужно каждый раз объяснять «у нас тут принято так».
Но для сложных фич всё равно работает связка: «сначала составь план реализации» → проверил → «теперь делай». Без этого на нетривиальных задачах уходит в сторону.
По 200K контекста — на практике ограничение бьёт реже, чем кажется. Агент сам подгружает файлы по необходимости. Проблемы начинаются, когда пытаешься в одном диалоге сделать слишком много разного.
Согласен, RAG сильно снижает галлюцинации — модель отвечает по найденному контексту, а не выдумывает.
Но 99% — оптимистично. Если релевантный чанк не нашёлся или retrieval вернул что-то похожее, но не то — галлюцинации вернутся. Плюс модель может "дофантазировать" детали, которых нет в контексте.
Fine-tuning тут тоже помогает: можно научить модель отвечать "не знаю" или "уточните вопрос" вместо выдумывания. Но да, это не основной его плюс.
Пост скорее про другое — формат вывода, доменный язык, скорость. Там RAG не поможет.
Отличный подход — применить паттерны сетевой безопасности к AI-инфраструктуре. Особенно ценно, что это дополнительный слой, а не замена существующих Python-решений.
Артём, отличная фиксация прецедента. Мы в digital-pro.tech пришли к похожим выводам, но с другой стороны — не разработка продукта, а автоматизация бизнес-процессов.
Паттерн красивый, только в реальности рушится на одной простой вещи. Агенты до сих пор не умеют сказать «а вот тут что-то не так, давай остановимся». Поэтому вместо команды получается конвейер, который нужно смотреть глазами...
Интересный механизм с «зоной ближайшего развития» — Proposer получает максимальную награду только когда Solver угадывает ровно раз из нескольких попыток. По сути, это автоматическая калибровка сложности без участия человека.
Сам наблюдаю такое у клиентов — люди без бэкграунда в разработке начинают пилить рабочие прототипы за неделю. Пока MVP — всё хорошо. Проблемы начинаются позже, когда код надо поддерживать и ты не до конца понимаешь что написал. Но для валидации идеи — инструмент огонь.
Хорошая систематизация. Из практики добавлю пару вещей, которые всплывают на продакшене:
Re-ranking — на больших базах top-K из векторного поиска часто притаскивает шум. Cross-encoder reranker сильно помогает с релевантностью.
По чанкингу — размер очень зависит от домена. Для юридических документов 800 символов мало (теряется контекст), для FAQ и 300 хватает. Тут только эксперименты.
Интересный момент про снижение барьера входа с $10M до нуля. На практике это означает, что конкуренция переместится с уровня «у кого лучше базовая модель» на уровень «у кого качественнее данные для дообучения под конкретную нишу».
Интересное сравнение. Результаты в целом совпадают с моим опытом использования этих моделей на реальных проектах.
Проблема «деменции» агентов — это реально боль. Сейчас решаю через детальный CLAUDE.md + принудительное «сначала составь план, я проверю» в начале каждой сессии. Работает, но костыльно: план всё равно приходится держать в голове или в отдельном файле.
Использую Claude Code на реальных проектах. Важный момент, который не сразу очевиден: хорошо написанный CLAUDE.md заметно сокращает количество итераций. Описал архитектуру, conventions, типичные паттерны — агент попадает в стиль кодовой базы с первого раза, не нужно каждый раз объяснять «у нас тут принято так».
Но для сложных фич всё равно работает связка: «сначала составь план реализации» → проверил → «теперь делай». Без этого на нетривиальных задачах уходит в сторону.
По 200K контекста — на практике ограничение бьёт реже, чем кажется. Агент сам подгружает файлы по необходимости. Проблемы начинаются, когда пытаешься в одном диалоге сделать слишком много разного.
Согласен, RAG сильно снижает галлюцинации — модель отвечает по найденному контексту, а не выдумывает.
Но 99% — оптимистично. Если релевантный чанк не нашёлся или retrieval вернул что-то похожее, но не то — галлюцинации вернутся. Плюс модель может "дофантазировать" детали, которых нет в контексте.
Fine-tuning тут тоже помогает: можно научить модель отвечать "не знаю" или "уточните вопрос" вместо выдумывания. Но да, это не основной его плюс.
Пост скорее про другое — формат вывода, доменный язык, скорость. Там RAG не поможет.
Отличный подход — применить паттерны сетевой безопасности к AI-инфраструктуре. Особенно ценно, что это дополнительный слой, а не замена существующих Python-решений.
Артём, отличная фиксация прецедента. Мы в digital-pro.tech пришли к похожим выводам, но с другой стороны — не разработка продукта, а автоматизация бизнес-процессов.