Долговременная память ИИ обсуждается так, будто главная беда системы – забывчивость. На практике беда обратная: система помнит слишком много и не понимает, что из этого уже неправда.
Ниже – чем это оборачивается для бизнеса, что говорят опубликованные замеры про попытки решить это моделью, и что показал наш корпус на 68 413 записей. Плюс проверка, которую можно провести у себя одним запросом.
Что такое «память» с точки зрения бизнеса
Три ситуации, в которых цена вопроса измеряется деньгами и репутацией.
Старая цена. В прошлом году клиенту дали скидку, в этом её отменили. Обе договорённости лежат в базе. Система отвечает менеджеру той, которая ближе по формулировке к его вопросу.
Бывший ответственный. Сделку вели трое подряд. «Кто ведёт этого клиента» – вопрос про сегодня, а база помнит всех.
Отменённая договорённость. «Мы обещали доставку до конца месяца» – обещали, потом перенесли. Если система об этом не знает, письмо клиенту уйдёт с прежним сроком.
Ни одна из трёх ситуаций не про объём памяти. Все три – про то, знает ли система, какая запись отменила какую.
Это и есть рабочее определение. Долговременная память ИИ – не хранилище всего сказанного, а порядок между записями: что действует сейчас, что действовало раньше, что отменено и когда.
Почему модель сама не решает, что новее
Здравый смысл подсказывает: покажем модели обе записи, она разберётся. Замеры говорят другое.
Первое. Отличить отменённый факт от простого повтора по близости текстов почти невозможно. В работе про временную достоверность в памяти это измерили прямо: надёжность различения – 0,59 при единице как идеале и 0,5 как случайном угадывании. Причина понятная: «цена 100 тысяч» и «цена 120 тысяч» похожи между собой сильнее, чем «цена 100 тысяч» и её же пересказ другими словами. Противоречие выглядит как близнец.
Второе. Когда такую систему заставляют ответить, она выдаёт устаревшее значение в 15–40 % случаев. Это не редкий сбой, а режим работы.
Третье, самое неприятное. Модель может найти свежее свидетельство и всё равно ответить старым. На бенчмарке STALE, где новое наблюдение отменяет старое без прямого отрицания, лучшая из проверенных моделей набрала 55,2 % общей точности. Авторы отдельно отмечают разрыв между «достать обновлённое свидетельство» и «действовать по нему».
Вывод для проектирования простой. Арифметику и формулировки модели отдавать можно. Решение «какая из двух записей главнее» – нет, это должно быть правило, которое можно прочитать глазами.
Долговременная память ИИ: нужен ли отдельный модуль
Вокруг этой задачи выросла целая категория продуктов: графы знаний, многоступенчатые конвейеры, планировщики в стиле операционной системы. Вопрос, который стоит задать подрядчику: что из этого решает описанную выше проблему.
Ответ по опубликованным сравнениям – ничего из архитектурной сложности. В работе ENGRAM авторы показали, что аккуратной разметки записей по типам и обычного поиска достаточно для лучших результатов на бенчмарке долгой памяти, а сложные архитектуры добавляют инженерных проблем и проблем с воспроизводимостью. Экономия при этом реальна, но она про другое: в их замере система использовала около процента токенов от объёма полного контекста.
То есть отдельная надстройка окупается стоимостью, а не правильностью. И это же снимает вопрос «зачем вообще что-то строить, если можно вывалить в модель всю выгрузку». На длинном контексте модели теряют точность: в замере NoLiMa 11 моделей из 13 на 32 тысячах токенов опустились ниже половины собственного результата на коротком тексте. Полная выгрузка выходит и дороже, и хуже отобранной горстки записей. А правильность даёт то, что стоит дешевле любой архитектуры:
| Что нужно памяти | Что это на практике |
|---|---|
| Тип записи | цена, ответственный, договорённость, статус – разные классы, а не «текст» |
| Срок действия | у записи есть дата начала и дата конца |
| Правило отмены | новая запись про ту же сущность и то же свойство отменяет старую |
| Происхождение | кто и когда это записал, из какого источника |
Правило отмены – ключевая строка. В том же замере детерминированное правило по тройке «объект, свойство, значение» свело долю устаревших ответов почти к нулю, причём без обращения к модели и без порогов похожести. И работает оно быстро: около двух секунд против шестнадцати-восемнадцати у варианта, где переставлять результаты просит модель. Про цену таких дополнительных проходов я подробно разбирал на замере поиска – там второй проход стоил от трёх до пятидесяти семи секунд.
Кейс: 68 413 записей и ни одной отменённой
Теперь наш пилот – та же клиентская база на 18 тысяч контактов, что и в остальных статьях цикла.
Мы построили хранилище утверждений: 68 413 записей, из них 50 756 действующих и 17 657 вытесненных более новыми версиями. Схема предусматривала двухвременность – у каждого утверждения должен быть интервал «действует с» и «действует по».
Отметку об окончании действия не несёт ни одна запись из 68 413. У всех интервал «с такого-то момента и навсегда».
Последствие выглядит так. Один и тот же вопрос к этой базе даёт два взаимоисключающих ответа, и оба формально верные:
| Как спрашивать | Сколько противоречий |
|---|---|
| Считать только действующие записи | 0 |
| Считать по интервалам действия | 649 |
649 объектов, где одно и то же свойство одновременно несёт два разных значения. Для отчёта, который фильтрует по «текущим», их не существует. Для системы, которая рассуждает по интервалам, компания живёт в противоречии.
Второй результат того же разбора: из 17 657 вытеснений 17 008 не изменили ничего. Поставщик данных сменил номер версии записи при массовом обновлении, а само значение осталось прежним. Реально изменили утверждение, ответственного или стадию сделки только 649 вытеснений – 3,7 %.
Отсюда практическое следствие, которое дороже всех остальных. Если систему учить на истории изменений, она будет учиться на данных, где 96 % событий – пустые. Отличать значимое изменение от технического приходится отдельно, и это тоже правило, а не модель.
Как проверить свою базу
Порядок, который не требует технических знаний и занимает часы.
-
Спросите, сколько записей в вашей базе помечены как отменённые или закрытые по дате. Ноль означает, что база хранит текущее состояние и не хранит историю. Это не поломка, это ограничение, но узнать о нём лучше до подписания договора.
-
Возьмите одно свойство, которое меняется: цена, ответственный, срок. Проверьте, сохраняет ли база прошлые значения или переписывает поле.
-
Попросите посчитать долю изменений, при которых значение осталось прежним. У нас таких оказалось 96 %, и это меняет любую оценку «в базе 17 тысяч событий».
-
Задайте один и тот же вопрос двумя способами – по текущим записям и по истории – и сравните ответы. Расхождение между ними и есть цена отсутствующего правила отмены.
-
На приёмке потребуйте тест «данные изменились»: поменяйте цену или ответственного в CRM и спросите систему через минуту. Демонстрация на неподвижных данных этого не проверяет никогда.
-
Спросите, что система ответит, когда обе версии записи одинаково подходят под вопрос. Правильных вариантов два: назвать действующую по правилу или сказать, что значений два. Выбор наугад правильным вариантом не является.
Тот же принцип, что и в остальных статьях цикла: проверять не обещание, а поле, на которое обещание опирается. Полный список вопросов подрядчику – в опорной статье про подключение ИИ к CRM, а идею отдельного слоя памяти нам рекомендовали отчёты глубокого исследования – как читать такие отчёты.
Границы этого замера
Наш корпус специфический. Это выгрузка одной CRM с короткими записями, где половина текстов – служебные пометки. На базе договоров или переписки соотношение будет другим, и долю пустых вытеснений нужно считать свою.
Чужие числа, на которые я ссылаюсь, получены на исследовательских наборах: диалоги, вымышленные пользователи, синтетические конфликты. Они показывают направление, а не ваш процент. Ни одна из этих работ не мерила русскоязычную CRM.
И честная оговорка про нас самих. Мы обнаружили отсутствие сроков действия не тогда, когда проектировали схему, – она была описана правильно, – а когда впервые посмотрели, что в хранилище лежит. Между этими двумя моментами прошло полтора месяца работы.
Замеры, которые отменяют наши же решения, я выкладываю в телеграм-канале по мере того, как они появляются. Хотите разобрать свой случай – пишите напрямую, @maslennikovig.
Наши замеры моделей, которые обновляются из базы, лежат в разделе бенчмарков. Про то, что бывает, когда систему принимают по демонстрации, есть разбор про пилоты без эффекта.
