Вроде начинаю понимать. Про этот симулятор агент знает больше, чем весь кожаный хабр вместе взятый, поэтому и справляется вообще любой моделью.
Про содержимое мозга нашего заказчика он может догадываться, угадывать его с весьма высокой вероятностью, но не абсолютно точно: частности знать не может.
Отсюда его скованность: мысль заказчика рушит шаблоны, навязывает логические цепочки, не укладывающиеся вообще ни во что.
Догмы заказчика имеют максимальный вес — это буквально догмы, и скованный агент выкручивается. Это все обычно происходит в малознакомом контексте (сепульки какие-нибудь), ну и всё: ему приходится выдумывать правила поведения, которые устроят всех, и он находит лазейки, которые археологи будущего расшифруют как глюки (а кто-то и сейчас верит в глюки ИИ).
Может, я не понимаю контекст. Никакая модель не может поправить модуль, если в нем отсутствует часть логики — вроде как есть рельсы, карта и семафоры, но вот горки и качество полотна сверху не видно.
Понятно, сейчас любая модель умеет проследить логические цепочки, а если что непонятно, так она выдумает и срежет углы. Любой модели нужны рамки, и все их создают по-разному, и, возможно, ваши рамки закрывают нашу боль, надо уточнять.
Про архитектуру, наконец-то, открыто написано — агентам это нельзя доверить, спасибо. Но я тут про логику и контекст, не архитектуру.
Статья действительно про узкое применение, если учитывать весь спектр задач к ИИ.
Конкретно про проекты (опуская, что они делаются ИИ-агентами и прочее), идущие несколько месяцев, где требования изменяются/рождаются на ходу и по ходу проекта формируются рамки, которые не хочется каждый раз повторять агенту.
Ваш случай 1 - простые проекты и ничего не прибито гвоздями и, скорее всего, не имеет продолжения. В раках большого проекта мы такое делаем пачками, отвечая на вопросы по ходу и не имея вообще проблем. Тут нет боли, поэтому и не пишем про такое.
Случай 2 - это как раз попытка одним коротким промптом поправить что-то в большом проекте, не поломав больше ничего. Самое приятное в работе с таким промптом, что агент подсвечивает тебе дефекты аналитики и крайние случаи, про которые ты и думать забыл — это прям особый кайф, такие случаи. Это часто экономит пару-тройку кругов ада, если вам знакома ситуация :-)
*) Ещё если вы буквально знаете как сделать сложную задачу от начала и до конца
Да-да! Я вот именно про это: я НЕ ЗНАЮ (тупо не помню) от начала и до конца, и вспоминать не хочу, потому что попутно делаю 3-4 проекта + текучку. Но то, что я однажды постиг и зафиксировал, помнит за меня агент.
Гейт можно поставить только на правило, у которого уже есть чёткий детерминированный инвариант, а такие в основном появляются постфактум, после второго-третьего тикета с одним и тем же рецидивом (см. историю с замороженным днём — сначала три прилёта, потом реестр). Заранее написать CI-проверку на «ссылка или подчинённая таблица» не получится, там не булево условие, а выбор из контекста: чек-лист с рассуждением или ничего. Ну и в статье прямо показано: даже где гейт есть, полдела делает требование написать RATCHET-OK: <почему> словами.
Модели — уже неинтересная утилитарная штука, которую нет стимула исследовать, а только эксплуатировать, поэтому о сезонности неудач мы даже не думали. Если бы я неоднократно поймал агента на чистой тупизне, я бы так и написал — «чаще всего» :-)
Да, чтобы писать промпты из одной фразы, без четкого ТЗ, надо вначале заморочиться подробной и однозначной инструкцией для агента — это потом окупается многократно.
Молодцы, особенно про reward hacking и рассинхрон train/inference.
Вопрос по агентным экспертам (Code Agent / General Agent): как модель ведёт себя с внешней памятью агента — когда в контекст на каждом шаге подмешиваются извлечённые из памяти факты и причинные цепочки прошлых инцидентов («симптом → причина → фикс»)? Интересует деградация в середине контекста на 100K+ и то, насколько reasoning-режим умеет опираться на подмешанное, а не переоткрывать всё заново — на других моделях мы видим, что качество агента упирается не в контекст, а именно в это.
Мы делаем графо-векторную память для ИИ-агентов (vecmory): семантический поиск + типизированные причинные рёбра между эпизодами, авто-recall на каждый ход агента, межсессионный обмен памятью между параллельными агентами. Гоняем её в проде на реальной разработке (тысячи узлов: тикеты, PR, выжимки инцидентов). Раз веса открыты — готовы поставить GigaChat 3.5 Reasoning ядром в этот контур, прогнать наши агентные сценарии (длинные многосессионные задачи с накоплением памяти) и вернуть развёрнутую обратную связь: где рассуждения помогают работе с памятью, где мешают (лишние токены на перепроверку уже известного — вы как раз пишете про −37% токенов). Если команде интересен такой тест — напишите, куда постучаться, будьте так добры.
Да, спасибо за разъяснения, я понимаю, как вы пришли к выводу о кликбейтности. Тем не менее, в заголовке не написано про «только gigachat», и статья описывает ровно то что в заголовке. Тесты не принижают Opus, а даже наоборот. Основная мысль про память, а не про сравнение моделей, и мы не делаем выводы кто лучше или хуже, а смотрим, кто насколько поднимается в конкретном применении.
Цену считал отдельно, на боевом инстансе, привожу.
Объём контекста. Бюджет фиксирован заранее: top_n=16, depth=2, в промпт уходит 12 узлов. Медиана инъекции: 6590 байт (1,5-2 тыс. токенов) на промпт, за период накопилось 1.2 МБ. Граф расходует ровно те же слоты, что и BM25: при одном размере выдачи меняется её состав. Поэтому +37 пунктов находимости (с 44% до 81%) достаются при том же объёме промпта.
Время. Латентность извлечения: медиана 1585 мс, p90 = 7,7 с против 16 мс в контрольной группе с выключенной памятью. Условия честные и неидеальные: общая машина с соседними сервисами, Postgres без pgvector, brute-force по 5967 узлам. Это верхняя граница, а не предел возможного — ANN-индекс (76 тыс. рёбер, сборка 101 с) даёт скорость, качество при этом остаётся тем же. Сам обход графа на depth=2 занимает малую долю; основное время съедают эмбеддинг запроса и косинус по корпусу.
Вклад в время ответа модели. Лишние ~2 тыс. токенов на prefill — десятки миллисекунд, на фоне полутора секунд ретрива и самой генерации это теряется. Прогон 100 вопросов через боевой garland занял 52 секунды на весь набор.
Пользователь, который сегодня мигрирует «на модель посильнее», на этом классе задач получил бы от памяти больше, чем от смены модели — дешевле и внутри своего контура.
Отдельно мне вот эта мысль понравилась:
Отдельно про деньги, раз уж они в таблице. Самая выгодная из семи — младшая gigachat-2: 0.21 ₽ за верный ответ против 1.85 ₽ у старшей и 1.66 ₽ у Opus. По точности она отстаёт от gigachat-2-max на шесть пунктов (51% против 57%), и эти шесть пунктов обходятся почти в девять раз дороже. Для потоковых задач, где ошибку ловит следующий шаг, выбор далеко не очевиден.
Если у вас, например, техподдержка или консалтинг, то вы можете заметно повысить качество обслуживания клиента, в рамках примерно того же бюджета и не прибегая к мощнейшим решениям, которые вам особо не нужны своей мощью. Не кодом единым.
Статья про то, как быть в отсутствие Claude. Замеры все есть, и когда я их показывал первым рецензентам, меня просили о сравнении. Вот оно, честное, проверяемое.
Предложите ваш вариант сравнения, и я с радостью сделаю. Спасибо.
Статья показывает ориентир для пользователей, кто не имеет возможности работать с продвинутыми моделями в своём контуре, как можно улучшить пользовательский опыт с тем что есть. Не «мы побили беззащитный Клод», а «вот вам рычаг — чуть подняться, примерно до уровня Клода». Отдельно хотелось бы услышать мнение разработчиков отечественных моделей — эти люди работают под натиском критики и сарказма, и им бы интересно было улучшить пользовательский опыт, а мне — заглянуть в будущее наших проектов. Вопросы в конце статьи.
А в каких конкретно "в корпоративных внедрениях" только векторный поиск реализован? Неужели такие корпоративы сегодня есть?
Про внедрения — тут поймали, статистики у меня нет. Это впечатление, а не данные: дефолт ходовых фреймворков — top-k по эмбеддингам, и то, что я вижу у заказчиков, тоже он. Назвать конкретные компании не могу. Точнее было бы написать «самый распространённый вариант из тех, что мне попадались», и как контрольная точка в замере он всё равно нужен — от чего-то надо отсчитывать.
Про динамическое — значит, я вас неправильно прочитал, простите. Тогда встречный вопрос: даже если веса подстраиваются под семантику запроса, факт «эту жалобу закрыл вот этот PR, вчера вечером» должен откуда-то взяться. Подстройка меняет то, как модель читает вход, а сам вход всё равно надо собрать. Плюс нужен доступ к весам, а корпоративный пользователь GigaChat или YandexGPT сидит на API, где такого рычага нет вообще. Если есть работающий пример на корпоративных данных с цифрами — киньте ссылку, я посмотрю и готов прогнать на нём свой набор вопросов.
Не манипуляция, а ориентир: Гига подтягивается к лидерам, и это лучше, чем если ничего не делать, и даже лучше в сравнении с тем, кто использует лидера как есть. Не всем доступен Клод, поэтому для них и написана эта статья, как ещё один способ достичь того, что уже есть у тех, у кого "всё хорошо".
Да, я понял мысль: границу надо обозначить в самом начале. Добавил в статью строку в верху.
Дополнил статью по итогам обсуждения — см. UPD.
Пара вопросов к тем, кто гоняет агента на потоке:
Где у вас проходит граница, после которой детализация перестаёт окупаться и начинает мешать?
Какие ещё слова оказались триггерами скованности? Соберём список, это полезнее всех моих частных рекомендаций.
Вроде начинаю понимать. Про этот симулятор агент знает больше, чем весь кожаный хабр вместе взятый, поэтому и справляется вообще любой моделью.
Про содержимое мозга нашего заказчика он может догадываться, угадывать его с весьма высокой вероятностью, но не абсолютно точно: частности знать не может.
Отсюда его скованность: мысль заказчика рушит шаблоны, навязывает логические цепочки, не укладывающиеся вообще ни во что.
Догмы заказчика имеют максимальный вес — это буквально догмы, и скованный агент выкручивается. Это все обычно происходит в малознакомом контексте (сепульки какие-нибудь), ну и всё: ему приходится выдумывать правила поведения, которые устроят всех, и он находит лазейки, которые археологи будущего расшифруют как глюки (а кто-то и сейчас верит в глюки ИИ).
Может, я не понимаю контекст. Никакая модель не может поправить модуль, если в нем отсутствует часть логики — вроде как есть рельсы, карта и семафоры, но вот горки и качество полотна сверху не видно.
Понятно, сейчас любая модель умеет проследить логические цепочки, а если что непонятно, так она выдумает и срежет углы. Любой модели нужны рамки, и все их создают по-разному, и, возможно, ваши рамки закрывают нашу боль, надо уточнять.
Про архитектуру, наконец-то, открыто написано — агентам это нельзя доверить, спасибо. Но я тут про логику и контекст, не архитектуру.
Статья действительно про узкое применение, если учитывать весь спектр задач к ИИ.
Конкретно про проекты (опуская, что они делаются ИИ-агентами и прочее), идущие несколько месяцев, где требования изменяются/рождаются на ходу и по ходу проекта формируются рамки, которые не хочется каждый раз повторять агенту.
Ваш случай 1 - простые проекты и ничего не прибито гвоздями и, скорее всего, не имеет продолжения. В раках большого проекта мы такое делаем пачками, отвечая на вопросы по ходу и не имея вообще проблем. Тут нет боли, поэтому и не пишем про такое.
Случай 2 - это как раз попытка одним коротким промптом поправить что-то в большом проекте, не поломав больше ничего. Самое приятное в работе с таким промптом, что агент подсвечивает тебе дефекты аналитики и крайние случаи, про которые ты и думать забыл — это прям особый кайф, такие случаи. Это часто экономит пару-тройку кругов ада, если вам знакома ситуация :-)
Да-да! Я вот именно про это: я НЕ ЗНАЮ (тупо не помню) от начала и до конца, и вспоминать не хочу, потому что попутно делаю 3-4 проекта + текучку. Но то, что я однажды постиг и зафиксировал, помнит за меня агент.
Гейт можно поставить только на правило, у которого уже есть чёткий детерминированный инвариант, а такие в основном появляются постфактум, после второго-третьего тикета с одним и тем же рецидивом (см. историю с замороженным днём — сначала три прилёта, потом реестр). Заранее написать CI-проверку на «ссылка или подчинённая таблица» не получится, там не булево условие, а выбор из контекста: чек-лист с рассуждением или ничего. Ну и в статье прямо показано: даже где гейт есть, полдела делает требование написать
RATCHET-OK: <почему>словами.Модели — уже неинтересная утилитарная штука, которую нет стимула исследовать, а только эксплуатировать, поэтому о сезонности неудач мы даже не думали. Если бы я неоднократно поймал агента на чистой тупизне, я бы так и написал — «чаще всего» :-)
За статью спасибо!
Да, чтобы писать промпты из одной фразы, без четкого ТЗ, надо вначале заморочиться подробной и однозначной инструкцией для агента — это потом окупается многократно.
Молодцы, особенно про reward hacking и рассинхрон train/inference.
Вопрос по агентным экспертам (Code Agent / General Agent): как модель ведёт себя с внешней памятью агента — когда в контекст на каждом шаге подмешиваются извлечённые из памяти факты и причинные цепочки прошлых инцидентов («симптом → причина → фикс»)? Интересует деградация в середине контекста на 100K+ и то, насколько reasoning-режим умеет опираться на подмешанное, а не переоткрывать всё заново — на других моделях мы видим, что качество агента упирается не в контекст, а именно в это.
Мы делаем графо-векторную память для ИИ-агентов (vecmory): семантический поиск + типизированные причинные рёбра между эпизодами, авто-recall на каждый ход агента, межсессионный обмен памятью между параллельными агентами. Гоняем её в проде на реальной разработке (тысячи узлов: тикеты, PR, выжимки инцидентов). Раз веса открыты — готовы поставить GigaChat 3.5 Reasoning ядром в этот контур, прогнать наши агентные сценарии (длинные многосессионные задачи с накоплением памяти) и вернуть развёрнутую обратную связь: где рассуждения помогают работе с памятью, где мешают (лишние токены на перепроверку уже известного — вы как раз пишете про −37% токенов). Если команде интересен такой тест — напишите, куда постучаться, будьте так добры.
Да, спасибо за разъяснения, я понимаю, как вы пришли к выводу о кликбейтности. Тем не менее, в заголовке не написано про «только gigachat», и статья описывает ровно то что в заголовке.
Тесты не принижают Opus, а даже наоборот. Основная мысль про память, а не про сравнение моделей, и мы не делаем выводы кто лучше или хуже, а смотрим, кто насколько поднимается в конкретном применении.
Добавил в статью Udate: сколько стоит контекст от связей
Цену считал отдельно, на боевом инстансе, привожу.
Объём контекста. Бюджет фиксирован заранее: top_n=16, depth=2, в промпт уходит 12 узлов. Медиана инъекции: 6590 байт (1,5-2 тыс. токенов) на промпт, за период накопилось 1.2 МБ. Граф расходует ровно те же слоты, что и BM25: при одном размере выдачи меняется её состав. Поэтому +37 пунктов находимости (с 44% до 81%) достаются при том же объёме промпта.
Время. Латентность извлечения: медиана 1585 мс, p90 = 7,7 с против 16 мс в контрольной группе с выключенной памятью. Условия честные и неидеальные: общая машина с соседними сервисами, Postgres без pgvector, brute-force по 5967 узлам. Это верхняя граница, а не предел возможного — ANN-индекс (76 тыс. рёбер, сборка 101 с) даёт скорость, качество при этом остаётся тем же. Сам обход графа на depth=2 занимает малую долю; основное время съедают эмбеддинг запроса и косинус по корпусу.
Вклад в время ответа модели. Лишние ~2 тыс. токенов на prefill — десятки миллисекунд, на фоне полутора секунд ретрива и самой генерации это теряется. Прогон 100 вопросов через боевой garland занял 52 секунды на весь набор.
статья как раз про наоборот:
Отдельно мне вот эта мысль понравилась:
Если у вас, например, техподдержка или консалтинг, то вы можете заметно повысить качество обслуживания клиента, в рамках примерно того же бюджета и не прибегая к мощнейшим решениям, которые вам особо не нужны своей мощью.
Не кодом единым.
Не уточнял про русский язык. Хотелось проверить на публичных бенчмарках, там не про русский язык, а про повторяемость и независимость.
Статья про то, как быть в отсутствие Claude. Замеры все есть, и когда я их показывал первым рецензентам, меня просили о сравнении. Вот оно, честное, проверяемое.
Предложите ваш вариант сравнения, и я с радостью сделаю. Спасибо.
Мы так и сравниваем, жига с наддувом дает больше скорости. Кому это актуально (феррари в госах нельзя) могут ездить быстрее таким образом.
Статья показывает ориентир для пользователей, кто не имеет возможности работать с продвинутыми моделями в своём контуре, как можно улучшить пользовательский опыт с тем что есть. Не «мы побили беззащитный Клод», а «вот вам рычаг — чуть подняться, примерно до уровня Клода».
Отдельно хотелось бы услышать мнение разработчиков отечественных моделей — эти люди работают под натиском критики и сарказма, и им бы интересно было улучшить пользовательский опыт, а мне — заглянуть в будущее наших проектов. Вопросы в конце статьи.
Про внедрения — тут поймали, статистики у меня нет. Это впечатление, а не данные: дефолт ходовых фреймворков — top-k по эмбеддингам, и то, что я вижу у заказчиков, тоже он. Назвать конкретные компании не могу. Точнее было бы написать «самый распространённый вариант из тех, что мне попадались», и как контрольная точка в замере он всё равно нужен — от чего-то надо отсчитывать.
Про динамическое — значит, я вас неправильно прочитал, простите. Тогда встречный вопрос: даже если веса подстраиваются под семантику запроса, факт «эту жалобу закрыл вот этот PR, вчера вечером» должен откуда-то взяться. Подстройка меняет то, как модель читает вход, а сам вход всё равно надо собрать. Плюс нужен доступ к весам, а корпоративный пользователь GigaChat или YandexGPT сидит на API, где такого рычага нет вообще. Если есть работающий пример на корпоративных данных с цифрами — киньте ссылку, я посмотрю и готов прогнать на нём свой набор вопросов.
Не манипуляция, а ориентир: Гига подтягивается к лидерам, и это лучше, чем если ничего не делать, и даже лучше в сравнении с тем, кто использует лидера как есть. Не всем доступен Клод, поэтому для них и написана эта статья, как ещё один способ достичь того, что уже есть у тех, у кого "всё хорошо".