Право AI-агента молчать — обложка

Часть 3 из 3 — «Память для AI-агентов» Почему правильная метрика — не accuracy, а ноль уверенно-неверных действий

Представь два сценария.

В первом — старший кардиохирург смотрит на снимок и говорит: «Не знаю. Здесь две конкурирующих гипотезы, симптомы перекрываются. Нужны дополнительные тесты — конкретно эти три, плюс КТ с контрастом. Пока я их не увижу, я не дам ответа, который бы стал защищать».

Во втором — молодой ординатор уверенно ставит диагноз за тридцать секунд, опираясь на похожий случай из учебника прошлой недели. Уверенно. Чётко. Без сомнений.

Кому из них ты бы доверил оперировать свою маму?

Каждый AI-агент, которого мы сегодня деплоим, — это второй врач. Уверенный. Быстрый. Никогда не говорит «не знаю». И именно поэтому ему нельзя доверять ничего более болезненного, чем переписать README.

Сегодня — как это изменить. Не алгоритмически. Архитектурно.


Гнилая метрика, которая нас всех отравила

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

GPT-4 берёт 86% на MMLU. Claude — 88%. Gemini — 90%. Лучше, лучше, ещё лучше. Цифра растёт.

Что эта цифра не показывает — оставшиеся 10–14%. Это не «ответы, которые модель не дала». Это уверенно сгенерированные неправильные ответы, визуально неотличимые от правильных. У модели нет лампочки «здесь я не уверен». Она генерирует всё с одинаковой текстовой уверенностью.

Когда ты используешь такую модель, чтобы писать заметки, — нормально. Когда используешь для продакшен-кода, медицинских решений, юридических заключений, финансовых транзакций — 10% уверенных галлюцинаций означают 10% случаев, когда система врёт тебе с прямым лицом.

Правильная метрика для продакшен-AI звучит иначе:

0% уверенно-неверных действий при приемлемом abstain rate.

Не «процент правильных ответов». А «процент неверных действий» — ноль. И отдельно — abstain rate: как часто система честно говорит «не знаю, нужны данные / верификация / уточнение». Ноль неверных действий плюс 30% abstain — это в десять раз более production-ready, чем 90% accuracy с 10% уверенных галлюцинаций.

Заметь: я не сказал «0% неверных ответов». Я сказал «0% неверных действий». Различие важно. Ответ — это слова. Действие — это коммит, транзакция, диагноз, API-вызов, изменение в проде. Слова можно перечитать и отбросить. Действие уже произошло.

И это разделение между «ответом» и «действием» — то, что архитектурно отсутствует в современных AI-агентах.


Abstain как first-class исход

Во второй части этой серии я выложил семь принципов настоящей памяти, и второй из них — strict mode. Краткое напоминание: прежде чем факт попадёт в контекст промпта, он проходит через ворота — источник, confidence, temporal validity, отсутствие нерешённых противоречий. Если ни один факт не прошёл — система возвращает abstain = true с явной причиной.

Есть деталь, которую хочется подчеркнуть отдельно. Abstain — это не ошибка. Это результат. Такой же first-class, как «ответ» или «действие». Если у твоего AI ровно два возможных исхода — «ответил» и «ошибся» — у него нет архитектурного места под честное «не знаю». А значит, он будет выдумывать.

В разумной системе минимум четыре исхода:

  • answer — достаточно evidence, ответ дан, действие выполнено
  • clarification request — частичный evidence, нужен ввод от пользователя
  • abstain → brain task — недостаточно evidence, записано как задача в backlog с явным запросом данных
  • escalation — есть противоречие, требующее ручного review

И последние три — это не fallback’и. Не «когда всё пошло не так». Это полноценные, ожидаемые, заложенные в дизайн пути.

Когда я прошу braincore найти решение про auth-flow на проекте, над которым мы три месяца работаем, — он находит. Когда я спрашиваю про проект, который только начал, где ничего не записано, — он не выдумывает. Он говорит: «У меня нет evidence на этот вопрос. Создал brain-task: собрать решения по auth, источник — наш текущий design-документ, владелец — ты. Когда заполнишь, спрашивай ещё раз».

Это не баг. Это правильное поведение. Заметь, что произошло: система меня не заблокировала. Не сказала «error, no data». Она превратила незнание в задачу, которая теперь живёт в её backlog’е и будет периодически напоминать о себе.


Self-Tasking. Мозг с backlog’ом, а не пассивная поисковая машина

Самое страшное в современных «AI-агентах» — что они пассивны. Они ждут промпт. Каждый. Раз. Не помнят ничего между сессиями. Нет внутреннего backlog’а. Не осознают, что у них есть нерешённые вопросы.

Это не «агент». Это функция в костюме агента. У функции есть вход и выход. У агента есть цели, состояние и собственные задачи между запросами.

В настоящем cognitive runtime есть отдельная сущность — brain tasks. Они автоматически порождаются:

  • truth.contradiction — найдено противоречие в knowledge graph → задача на разрешение
  • truth.staleness — факт давно не подтверждался → задача на верификацию
  • strict.abstain — система отказалась отвечать → задача на сбор evidence
  • selflearn.skill_scorecard — навык начал часто падать → задача на починку
  • specs.evidence_gap — требование без покрытия → задача на сбор
  • tests.failing_coverage — тесты не проходят → задача на починку
  • learning.failure_pattern — обнаружен повторяющийся паттерн ошибки → задача на обобщение в правило

У каждой задачи есть самоприоритизация по простой формуле:

priority = f(urgency, impact, confidence, risk, effort, dependency_readiness)

И в любой момент пользователь может спросить: «покажи следующие пять задач, почему они важны, какие я могу безопасно сделать сейчас, какие требуют моего ввода». Это не тот же чат, в котором каждый раз стартуешь с чистого листа. Это рабочая среда с собственной памятью о том, что не сделано.

Это смена кадра. Не «пользователь приходит и спрашивает, агент отвечает». А «агент работает в фоне, накапливает открытые потоки и сам говорит — вот что важно сейчас».

Покажи мне RAG-стек, который так умеет. Спойлер: его нет. Потому что RAG — это поисковик, а не агент. И когда кто-то говорит «у нашей RAG-AI есть agency» — это маркетинговая фантазия. Agency требует внутреннего состояния, целей, backlog’а и self-assessment. Ничего этого в RAG нет.


Cognitive Runtime > размер модели

Последний миф к разрушению.

«Когда выйдет GPT-5 / Claude 5 / Gemini 3 — память решится сама». Нет. Не решится. Никогда.

Память — это не свойство модели. Это свойство системы, в которой модель работает. Аналогия:

У человека хорошая память не потому, что нейроны быстро считают. У человека хорошая память потому, что есть гиппокамп, неокортекс, консолидация во сне, эмоциональная фильтрация через миндалевидное тело и архитектурное разделение между working / episodic / semantic / procedural memory. Это инфраструктура, а не вычислительная мощность.

Сделай LLM в десять раз больше — память не появится. Построй runtime вокруг существующей LLM, реализующий семь принципов из части 2 плюс abstain плюс self-tasking — и слабая локальная модель в этом runtime начнёт делать вещи, которые GPT-5 с RAG-памятью архитектурно не может.

Не потому что она умнее. А потому что runtime делает за неё то, что она сама делать не должна: помнит, верифицирует, отказывается, ставит себе задачи.

Это, кстати, единственный осмысленный путь вперёд в мире, где foundation-модели — это commodity. Когда у всех примерно эквивалентные Claude/GPT/Gemini — конкурентное преимущество может прийти только из того, что вокруг модели. Domain-specific cognitive runtime. Project-specific memory. Team-specific rules.

И эта ставка — ещё и про privacy. Про data sovereignty. Про то, что память твоего проекта — это твой капитал, и сдавать её в аренду стороннему vector DB за ежемесячную плату — стратегическая ошибка, которую заметишь только через три года, когда уже не сможешь уйти.

Поэтому, кстати, braincore — это локальный Go-бинарь, который по умолчанию работает без OpenAI и без Anthropic. Не потому что я против них (я платящий клиент обоих). А потому что архитектурно правильный путь — это runtime, в котором модель — заменяемый компонент, а не центр тяжести.


Чек-лист для всех, кто строит AI-продукты прямо сейчас

Если ты прочитал всю серию и думаешь «окей, согласен, что мне делать в понедельник утром?» — вот десять пунктов, по которым можно начать двигаться независимо от того, используешь ты braincore или нет.

  1. Убери слово «память» из стека, если у тебя RAG. Назови это retrieval или search — это мгновенно снимет 80% завышенных ожиданий.
  2. Введи truth_status для каждого факта. Минимум: hypothesis | confirmed | deprecated. Запрети confirmed без source_ref.
  3. Введи valid_from / valid_until. Любой факт без temporal validity — это гипотеза, не факт.
  4. Сделай abstain first-class исходом. Не «когда всё плохо» — а как один из четырёх валидных результатов.
  5. Различай staging | working | consolidated | archived. Не сваливай всё в одну коллекцию.
  6. Negative memory. Что сломалось — записывай явно, со ссылкой на failing-тест или коммит.
  7. Entity disambiguation. Никогда не сливай сущности при низкой confidence. Создавай ambiguity record.
  8. Causal chains для решений. Не «текст» — problem → alternatives → decision → reasoning → outcome.
  9. Локально, где можно. Память проекта — твой капитал.
  10. Метрика — не «процент правильных ответов». А 0% wrong actions при приемлемом abstain rate.

Не всё сразу. Возьми два-три и начни. Через месяц у тебя будет AI-система, которой можно доверять больше, чем большинству существующих.


Эпилог. Когнитивная гигиена для AI-индустрии

Я устал от того, что слово «память» шлёпают на каждую векторную базу с эмбеддингами. Это девальвация термина — как назвать таблицу с одной колонкой text VARCHAR базой знаний. Технически — да. По сути — нет.

Память — это:

  • структура, а не плоский список
  • знание границы, а не уверенный bullshit
  • причинные цепочки, а не чанки
  • entity-aware, а не string-aware
  • temporal-aware, а не «создано вчера, валидно вечно»
  • самокорректирующаяся, а не самообманывающая
  • управляемая, а не «сваливай что попало, потом разберёшься»
  • способная к abstain, а не «всегда отвечает»

Если твой «AI с памятью» не делает хотя бы половины из этого — у твоего AI нет памяти. У него есть результаты поиска. Это разные вещи.

Последнее. Я не призываю выкинуть RAG. RAG — отличный инструмент для своего класса задач (найди мне абзац про X в 100 документов). Я призываю перестать называть RAG памятью и начать строить настоящие cognitive runtime — медленнее, дисциплинированнее, с явными воротами и явным abstain. Это единственный путь к AI-системам, которым можно доверить что-то более важное, чем переписать README.

Если ты стартап с «у нашего AI long-term memory на векторной базе» в питч-деке — закрой этот слайд, переделай, и через два года скажешь себе спасибо.

Если ты разработчик, борющийся с агентом, который забывает, что ты говорил вчера, — это не вина агента. Это вина того, кто продал тебе поисковик в обёртке мозга.

Хороший AI-агент — это не тот, кто всегда отвечает. Хороший AI-агент — тот, кто никогда не делает уверенно-неверного действия. Между этими двумя предложениями — вся пропасть, отделяющая AI-инструменты 2024-го от AI-инструментов, которым можно будет доверять в 2027-м.

Я выбрал свою сторону пропасти. Строю braincore — открытый, Apache-2.0, в репо. Если узнал себя в этой серии — мы в одной лодке. Если в твоём стеке что-то работает иначе — расскажи, я серьёзно хочу знать.

Чего ты точно не можешь — это молчать.


TL;DR всей серии:

  • Часть 1: RAG = Ctrl+F с эмбеддингами. Это поиск, а не память. Mem0/Letta/Zep — RAG в обёртках. 1М контекст — это RAM, а не диск.
  • Часть 2: Настоящая память = семь принципов в комбинации. Атомарные единицы + lifecycle + truth_status + temporal + причинные цепочки + AST-идентичность + internal git + memory scoring + negative memory. Каждое существует по отдельности. В сборе — другой продукт.
  • Часть 3: Метрика для продакшен-AI — не accuracy, а 0% уверенно-неверных действий. Abstain — first-class исход, а не ошибка. Cognitive runtime > размер модели.

Если твой AI «помнит» через vector_db.query(top_k=5) — у него деменция, замаскированная под уверенность. Чини архитектуру, а не модель.


Часть 3 из 3. Серия завершена. Если откликнулось — поделись. Если не согласен — напиши в комментариях, я люблю содержательные споры.