GigaChat 2 Max с памятью на связях обходит Claude Opus 5 без неё: замер семи моделей

Кратко: на классе задач «в работе всплыла проблема — каким изменением её уже чинили»:
GigaChat 2 Max с памятью на связях отвечает верно в 57% случаев,
YandexGPT Pro 5.1 — в 61%,
Claude Opus 5 с обычным поиском — в 41%.

Модели никто не трогал: разница целиком в том, доехал ли до модели нужный факт в контексте.

Важная оговорка про метрику, которая есть статье: Claude Opus 5 с той же памятью даёт 68% — больше всех в замере. Сравнение в заголовке про другое: обе стороны реального выбора «остаться на своей модели или мигрировать на зарубежную» сегодня работают на обычном поиске — по словам или по смыслу, без связей между записями.

Связи здесь — типизированные рёбра между записями: «эту проблему закрыло вот это изменение», «за этой задачей последовала вон та», «здесь речь про тот же объект». Дальше в статье видно, сколько дают именно они: поиск по смыслу сам по себе — 46%, вместе со связями — 84%. Хранится это в обычном PostgreSQL, без расширений: почему голая EAV-модель на таких данных разваливается и какие три слоя пришлось добавить, чтобы она держала нагрузку, я разбирал отдельно.

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

Откуда это взялось. Мы делаем конструктор баз данных и приложений Интеграм, и сама разработка идёт с ИИ-агентом — хочется поднять его эффективность и уменьшить количество ошибок, особенно повторяющихся. Слой памяти вырос из этой задачи как побочный проект, причём идею нам подсказал сам агент: он регулярно упирался в то, что уже было решено, и однажды на вопрос «ДОКОЛЕ?» предложил хранить не переписку, а связи «жалоба → изменение, которое её закрыло». Итак, про замеры.

Что меряли

Задача самая обычная для поддержки и разработки: пришла жалоба — найти изменение, которое эту проблему уже закрывало.

• Корпус — реальный рабочий проект: 4618 задач и изменений, русский язык.

• 100 вопросов, правильный ответ известен заранее из истории проекта.

• Проверка автоматическая — сверяется номер. ИИ-судью не спрашиваем: оценка не «плывёт» между прогонами, и её может перепроверить кто угодно.

• 2310 обращений к моделям: 7 моделей × (30 + 100 + 100 + 100).

Четыре режима, одинаковых для всех моделей — сравниваются модели, а не поисковики:

Из чего собрана память

Результаты

В ячейках — доля верных ответов из ста вопросов, сверка по номеру. Четыре средние колонки — те самые режимы: none без всякого контекста, kw с поиском по словам, vecmory с памятью на связях, mc с гарантированно вложенным ответом. мед. мс — медианное время ответа самой модели, поиск в него не входит. Про ₽/верный — сразу под таблицей.

₽/верный — во что обходится один правильный ответ: стоимость всех вызовов, делённая на число верных. Промахи в знаменатель не попадают, но за них заплачено, поэтому это цена результата, а не цена удачного запроса. Стоимость каждого вызова возвращает шлюз, так что числа не из прайса, а по факту.

Три вещи, которые тут видно.

Первое. При наивном поиске все семь моделей лежат в коридоре 32–42%. Opus 5 — 41%, GigaChat 2 Max — 40%, YandexGPT Pro — 42%. На этом классе задач разрыв между «дорогой» и «дешёвой» моделью почти не проявляется, потому что упирается он не в ум модели, а в то, что нужный факт до неё не доехал.

Второе. Память добавляет каждой модели 14–27 пунктов. И заметьте: дорогой Opus выигрывает от неё больше (+27), чем GigaChat 2 Max (+17). Слой одинаково нужен и тем, кто уже сидит на флагманской модели.

Третье, ради чего всё писалось. GigaChat 2 Max с памятью — 57%. Claude Opus 5 с обычным поиском — 41%. Пользователь, который сегодня мигрирует «на модель посильнее», на этом классе задач получил бы от памяти больше, чем от смены модели — дешевле и внутри своего контура.

Разрыв между моделями при этом никуда не делся: при одинаковом контексте Opus даёт 68% против 57%, а в идеальных условиях — 89% против 71%. Эти 18 пунктов памятью не закрываются, их закрывает только работа над самой моделью.

Отдельно про деньги, раз уж они в таблице. Самая выгодная из семи — младшая gigachat-2: 0.21 ₽ за верный ответ против 1.85 ₽ у старшей и 1.66 ₽ у Opus. По точности она отстаёт от gigachat-2-max на шесть пунктов (51% против 57%), и эти шесть пунктов обходятся почти в девять раз дороже. Для потоковых задач, где ошибку ловит следующий шаг, выбор далеко не очевиден.

Самое интересное — строка, похожая на опечатку

У младшей gigachat-2 контрольный режим (42%) хуже режима с памятью (51%). Хотя в контрольном нужный ответ гарантированно лежит перед моделью.

Причина отрезвляет: младшая GigaChat в 31% случаев называет номер, которого в контексте не было. Она уверенно выдаёт конкретный номер — в режиме, где правильный ответ лежит прямо перед ней среди двенадцати кандидатов.

Для сравнения, в том же режиме: Claude Opus 5 не выдумывает ни разу (0%), YandexGPT Pro 5.1 — в 1% случаев, GigaChat 2 Max — в 2%. Так что дело не в «русских моделях вообще», а в конкретной младшей модели, и это ровно та часть, которую не лечит никакой поиск.

Механика простая: слабую модель лишние похожие факты сбивают сильнее, чем сильную. Двенадцать кандидатов для неё — поле для фантазии вместо реальной помощи.

Отсюда главное правило: чем слабее модель, тем важнее отдавать ей мало и точно. Три точных факта работают лучше двенадцати похожих. Гонка за полнотой поиска (recall) для слабых моделей контрпродуктивна — им нужна точность выдачи (precision).

Сколько из этого прироста настоящее?

В прошлой статье мне возразили: прирост может держаться на том, что память ходит по ссылкам «эта задача закрыта этим изменением», а правильный ответ в замере определяется по тем же ссылкам. Замер тогда не отличает «память хорошо ищет» от «памяти заранее подсказали».

Я разложил вклад — вот результат на том же наборе из 100 вопросов, метрика «нужный документ попал в 12 кандидатов»:

Поиск по смыслу даёт 46% — практически вровень с поиском по словам. Это для тех, у кого «векторный поиск уже стоит»: сам по себе он добавляет к обычному поиску два пункта. Вся остальная разница до 84% приходит из связей между записями. И да, эта часть замера тавтологична: gold определён по тем же рёбрам, по которым ходит граф.

Почему так получается, видно на конкретном примере. Вопрос — текст жалобы («даты по API приходят в формате DD.MM.YYYY»). Модель похожести (эмбеддер) уверенно находит саму жалобу (косинус 0.92) — это её настоящая работа, и совпадения слов для неё не нужно. Но нужен-то не дубль жалобы, а PR, который её починил, а текст фикса написан совсем другими словами: «исправлен парсинг дат». Между жалобой и фиксом косинус слабый. Шаг от одного к другому делает граф, а не модель похожести.

Точная формулировка такая: модель похожести находит вход в цепочку, граф делает шаг к решению; по отдельности ни один из них 84% не даёт.

Второй замер в ту же сторону. Вопросы в наборе — дословные заголовки задач, то есть первый шаг поиска в них бесплатный. Если задать тот же вопрос чужими словами, доставка нужного факта падает с 75% до 50% — при 44% у наивного поиска, то есть почти в полосу шума. Лечится это моделью похожести: на multilingual-e5-large доставка переформулированного запроса — 87%.

Проверка на чужом поле

Чтобы числа не висели на одном моём корпусе, я прогнал поиск на публичных наборах — musique, 2wikimultihopqa, hotpotqa в раздаче HippoRAG, тех самых файлах, на которых опубликованы полнота@2 и полнота@5 (Recall@2/@5 — доля вопросов, где нужный документ попал в первые 2 или 5 найденных) для BM25, Contriever, GTR, GritLM-7B, NV-Embed-v2, RAPTOR и HippoRAG 2 (arXiv:2502.14802, табл. 9). Разметку и метрику перенёс из их кода построчно.

BM25 обойдён на всех трёх наборах, на 2Wiki — и RAPTOR. Полный путь на HotpotQA даёт полноту@2 80.5 — выше GritLM-7B (79.2) и в трёх пунктах от HippoRAG 2 (83.5). Моделям на 7 млрд параметров по полноте@5 я проигрываю, так в таблице и написано.

При этом: модель на 384 измерения, 130 МБ, CPU, без GPU и без ключей, 4–8 мс на запрос.

Проверить меня можно легко — вот гист: один файл без моего кода, скачивает наборы, печатает sha256 и пересчитывает строку плотного поиска.

Оговорки про эти числа

• Один класс задач — «вспомнить, что уже было». Про задачи вида «связать пять фактов и сделать вывод» замер не говорит ничего.

• 100 вопросов — это ±10 пунктов. Разница 40% против 41% означает «неразличимо». Российские флагманы между собой неразличимы: YandexGPT Pro 5.1 выше GigaChat 2 Max по сырым процентам на всех режимах, но парный тест не подтверждает ни одного расхождения (p от 0.180 до 0.625). Так что «Яндекс обошёл Сбер» из этих данных не следует.

• Прирост памяти — верхняя граница, см. раздел про разложение вклада.

• Таблица семи моделей стоит на одном корпусе и одном языке. Публичные наборы выше проверяют только доставку контекста — сравнения моделей там нет. Переносятся ли эти проценты на другой корпус и другой язык, я пока не проверял.

• Причинные рёбра — то, ради чего всё делалось — на википедийных наборах не меряются вообще.

• Цены сняты на двух шлюзах (GigaChat — через одного посредника, Claude и Яндекс — через другого), поэтому рубли сравнивают в том числе два прайса: порядок величины разрыв переживёт, второй знак — нет.

К командам GigaChat и YandexGPT — если читаете

У меня один корпус, сто вопросов и ±10 пунктов интервала. У вас — внутренние замеры на данных, которых я никогда не увижу. Поэтому вопрос по существу: на ваших прогонах разрыв с зарубежными моделями тоже упирается в доставку контекста, а не в сами модели? Если да — это меняет то, куда осмысленно вкладывать усилия. Если на ваших данных выходит иначе, буду премного благодарен за пару строк в комментариях: интересно понять, где расходятся условия.

Методика открыта целиком: набор вопросов, скрипты замера и 2310 сырых ответов моделей лежат в репозитории, а строка публичного замера пересчитывается гистом вообще без моего кода. Повторить на своём корпусе — работа на день, и это единственный способ проверить, переносится ли прирост на ваши данные.

И отдельно про 31% выдуманных номеров у младшей GigaChat: это находка, которую починить дешевле, чем догонять фронтир размером модели.

Что с этим делать

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

Если вы делаете модель — 18 пунктов из разрыва (с 71% до 89% в идеальных условиях) не закрывает никакой поиск. Это ровно та часть, где нужный ответ уже лежит перед моделью, а она им не воспользовалась.

Сырые данные — 2310 ответов моделей с токенами, ценой, шлюзом и латентностью — лежат в репозитории вместе со скриптами замера. Вопросы и возражения по методике приветствую: прошлый раз именно из комментариев вышел самый полезный вопрос, который заставил меня разложить вклад модели похожести и графа по отдельности.