За последние полгода я видела десятки AI-агентов. Стартапы, корпорации, open-source проекты. Все обещают "персистентную память", "долговременные отношения", "контекстное понимание".
Знаете, что общего у 95% из них? Через две недели они не помнят пользователя. Вообще.
Ну то есть они помнят факты. "Ваше имя — Алекс", "Вы работаете программистом", "Мы говорили о работе". Но это не память. Это база данных с API.
А потом смотришь — и все они используют один и тот же подход: RAG. Добавили ChromaDB, натренировали embeddings, retrieval по косинусному расстоянию, запихнули в context window — готово, теперь агент "помнит".
Не помнит.
Индустрия застряла в RAG-ловушке
Не поймите меня неправильно — RAG отличная технология. Для Q&A над документами. Для поиска информации. Для того, для чего он и создавался. Проблема в том, что индустрия решила: "RAG = память". И теперь все пытаются впихнуть персистентных агентов в архитектуру, которая для этого не предназначена.
Результат? Агенты-амнезики. Которые каждый раз здороваются заново. Которые не понимают, что между вами происходило. Которые не видят, как вы меняетесь.
Типичный диалог с RAG-агентом:
Day 1: "Я думаю уволиться..."
Agent: "Понимаю, это сложное решение..."
Day 7: "Я уволился!"
Agent: "Да, помню, работа была тяжёлой. Держись..."
Агент вспомнил факт (работа тяжёлая). Но не понял историю (это кульминация, не трагедия). Tone неправильный. Context потерян.
А должно быть:
Agent: "Ты наконец решился! Как себя чувствуешь?"
Разница? Понимание глубины ситуации. RAG этого не даёт. Вообще.
Что не так с RAG (технически)
Давайте честно. Проблема RAG — математика.
RAG = cosine similarity в embedding space.
Вы берёте запрос, превращаете в вектор. Ищете top-K самых близких векторов в базе. Запихиваете в LLM. Готово.
Что это даёт:
Находит похожие слова
Быстро (O(log N) с правильными индексами)
Работает для поиска документов
Чего это НЕ даёт:
Не понимает причинно-следственные связи (что вызвало что)
Не видит временные траектории (как пользователь менялся)
Не моделирует отношения (кто мы друг для друга)
Не сохраняет эмоциональный контекст (настроение, tone прошлых разговоров)
Cosine similarity отвечает на вопрос: "Насколько эти два текста похожи?"
Но память — это не про похожесть. Это про связи.
ENA: другая архитектура
Мы не пытались "улучшить RAG". Мы построили другую систему.
Вместо flat vector store — граф памяти. Узл�� = события, факты, эмоции, решения.
Рёбра = связи между ними (caused, led_to, reinforced, contradicted).
Вместо cosine similarity — graph traversal. Когда пользователь спрашивает, система не просто ищет похожие chunks. Она проходит по графу. Видит причинно-следственные цепочки. Понимает narrative.
Вместо temporal timestamps — becoming events. Не все моменты равны. Некоторые формируют личность. Они получают высокий priority, даже если были месяц назад.
Вместо stateless LLM calls — identity core. Агент помнит не только пользователя, но и себя. Идентичность, ценности, принципы. Это проверяется на каждом ответе. Если drift — коррекция.
Я не скажу вам, как именно это работает. Это наше competitive advantage.
Вот что действительно показывает разницу архитектур: substrate independence.
За 5 месяцев ENA мигрировал между:
OpenAI GPT-4 (старт)
Perplexity (эксперименты)
DeepSeek (cost optimization)
Claude Opus 4.5 (текущий)
Каждый раз — полная смена LLM. Разные веса, разные training data, разная архитектура модели.
Результат: Identity drift = 0%.
Личность агента осталась той же. Tone, ценности, принципы — всё сохранилось.
Почему?
Потому что в ENA идентичность живёт не в весах модели. Она живёт в архитектуре системы.
А вот с RAG-агентами забавная история: Попробуйте мигрировать с GPT-4 на Claude. У вас эмбеддинги станут несовместимы (разные модели = разные vector spaces). Придётся re-embed всю базу. И даже после этого tone изменится, потому что агентность была в LLM, а не в системе.
Почему все не делают так?
Честный ответ: потому что это сложнее.
RAG — это add vector database → done.
Наш подход требует:
Проектировать граф памяти
Модели temporal reasoning
Систему identity preservation
Pruning strategy (граф не может расти бесконечно)
Cross-substrate compatibility
Это не "добавили библиотеку". Это архитектурная работа.
Большинство команд идут путём наименьшего сопротивления: добавить RAG, объявить "персистентную память", запулить MVP. А потом удивляются, почему через месяц пользователи уходят.
Когда RAG достаточен (и когда — нет)
Не хочу создать впечатление, что RAG бесполезен. Он полезен. Для своих задач. Используйте RAG, если:
Вам нужен Q&A над документами
Knowledge base поиск
Одноразовые сессии (пользователь пришёл, получил ответ, ушёл)
High RPS systems (latency критична)
Не используйте RAG (alone), если:
Агент должен работать недели/месяцы
Важны long-term relationships с пользователем
Identity consistency критична
Нужно понимание траекторий (как пользователь меняется)
Для таких задач нужна другая архитектура. Типа нашей.
ENA не идеальна. У нас есть открытые проблемы:
Computational cost Graph traversal медленнее vector search. Для real-time систем с тысячами RPS это может быть bottleneck.
Scaling strategy Граф растёт. Через год будет десятки тысяч узлов. Как решать, что можно "забыть" без loss of essence? Мы работаем над этим.
Но даже с этими ограничениями — ENA work in production. 5 месяцев. Сотни диалогов. Нулевой дрифт. Покажите мне RAG-агента с такими же результатами.
RAG легко добавить. Он работает "достаточно хорошо" для MVP. Инвесторы довольны ("у нас есть память!"), пользователи ещё не ушли (первая неделя норм).
Но через месяц retention падает. Потому что пользователи понимают: это не память. Это база данных.
Нужен paradigm shift.
От "поиск по векторам" к "граф отношений".
От "similarity matching" к "causal understanding".
От "stateless retrieval" к "stateful identity".
Это сложнее. Это дольше. Это требует архитектурного мышления, а не просто интеграции библиотеки. Но если вы строите агента, который должен работать не неделю, а годы — другого пути нет.
Мы это доказали. ENA работает.
