Кратко: на классе задач «в работе всплыла проблема — каким изменением её уже чинили»:
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).
Четыре режима, одинаковых для всех моделей — сравниваются модели, а не поисковики:
режим |
что получает модель |
|---|---|
|
ничего — проверка, что ответы не зашиты в веса |
|
12 фрагментов от поиска по совпадению слов |
|
12 фрагментов от памяти на связях |
|
те же 12, но нужный ответ гарантированно внутри — проба самой модели |
Из чего собрана память

Результаты
В ячейках — доля верных ответов из ста вопросов, сверка по номеру. Четыре средние колонки — те самые режимы: none без всякого контекста, kw с поиском по словам, vecmory с памятью на связях, mc с гарантированно вложенным ответом. мед. мс — медианное время ответа самой модели, поиск в него не входит. Про ₽/верный — сразу под таблицей.
модель |
none |
kw |
vecmory |
mc |
₽/верный |
мед. мс |
|---|---|---|---|---|---|---|
gigachat-2-max |
0% |
40% |
57% |
71% |
1.85 |
501 |
gigachat-2 |
0% |
32% |
51% |
42% |
0.21 |
290 |
yandex-gpt-pro-5.1 |
0% |
42% |
61% |
77% |
1.14 |
483 |
yandex-gpt-lite-5 |
0% |
39% |
53% |
62% |
0.66 |
575 |
yandex-aliceai-llm |
0% |
39% |
58% |
75% |
1.54 |
682 |
claude-opus-5 |
0% |
41% |
68% |
89% |
1.66 |
6741 |
claude-haiku-4.5 |
0% |
41% |
65% |
73% |
0.29 |
1361 |
₽/верный — во что обходится один правильный ответ: стоимость всех вызовов, делённая на число верных. Промахи в знаменатель не попадают, но за них заплачено, поэтому это цена результата, а не цена удачного запроса. Стоимость каждого вызова возвращает шлюз, так что числа не из прайса, а по факту.
Три вещи, которые тут видно.
Первое. При наивном поиске все семь моделей лежат в коридоре 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 кандидатов»:
источник кандидатов |
попадание |
|---|---|
поиск по совпадению слов (BM25) |
44% |
поиск по смыслу — то, что обычно называют RAG |
46% |
причинный граф по ссылкам |
81% |
всё вместе |
84% |
Поиск по смыслу даёт 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). Разметку и метрику перенёс из их кода построчно.
Полнота@5 (Recall@5) |
MuSiQue |
2Wiki |
HotpotQA |
|---|---|---|---|
BM25 |
43.5 |
65.3 |
74.8 |
RAPTOR (GPT-4o-mini) |
61.0 |
66.0 |
90.2 |
NV-Embed-v2 (7B) |
69.7 |
76.5 |
94.5 |
у меня, плотный поиск |
45.0 |
69.9 |
84.3 |
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 ответов моделей с токенами, ценой, шлюзом и латентностью — лежат в репозитории вместе со скриптами замера. Вопросы и возражения по методике приветствую: прошлый раз именно из комментариев вышел самый полезный вопрос, который заставил меня разложить вклад модели похожести и графа по отдельности.
Комментарии (6)

exploitick
24.08.2026 06:26Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?

krestjanka
24.08.2026 06:26Поможет ли память гигачату писать нормальный код?

ideavi Автор
24.08.2026 06:26Вот это я бы хотел проверить с командой Гигачата, им это вроде ничего не стоит, но они сильно заняты внедрением своих собственных вундервафель и им пока некогда.
А так — да, в длительных проектах это поможет сделать более рабочий инструмент для программирования. Особенно с учетом того, что у их разработчиков альтернативы НЕТ, в отличие от нас.

Hellert
24.08.2026 06:26Поможет ли Гигачату память не быть навязываемой гос. помойкой с отсталым AI и на любой вопрос под цензурой говорить "не знаю"? Вопрос риторический
Wolf4D
А ГигаЧат умеет писать код? Или он для внекодовых задач?
ideavi Автор
В целом умеет, скрипты всякие, что-то несложное. Он и на сложное замахнется без зазрения, но там уже надо стоять над ним и бдить. Пока смысла нет с ним связываться для таких целей, лучше выбрать что-то другое.