Память: концепция и измеренные результаты
Мы строим долговременную память для команд и их агентов: знания живут в человекочитаемых документах, поверх - поисковый индекс, семантика и граф связей. Здесь - сама концепция и то, что мы намерили, когда проверили ее на двух корпусах против ручной валидации по первоисточникам и на открытом корпусе в тысячи документов.
Три принципа памяти
Все разворачивается в изолированном контуре заказчика и остается в его инфраструктуре.
Граница генеративности: детерминированный слой и агент
Языковая модель работает только у агента-читателя, который формирует ответ. Весь путь записи и производные индексы детерминированы: источник истины хранится побайтно, а индекс полностью перестраивается из него переиндексацией. Именно это отличает подход от систем памяти на LLM-экстракции сущностей.
Три типа ребер графа строятся на момент записи, без обращения к модели: явные ссылки, «призрачные» (разрешаются автоматически, когда упоминаемый документ появляется) и упоминания по имени с учетом словоизменения.
Как мерили: два корпуса, ручной референс, четыре типа вопросов
Эталон строился вручную: для каждого вопроса ответ выверялся чтением первоисточников - референс по построению равен 100%. Вопросы четырех типов: точные термины (идентификаторы, номера, версии), парафразы без словарных совпадений, multi-hop (ответ размазан по нескольким связанным документам) и негативные (ответа в корпусе нет). Метрики - попадание нужного документа в топ-5 выдачи и полнота: найдены ли все документы, требуемые для полного ответа.
| Корпус | Состав | Вопросов | Что проверяет |
|---|---|---|---|
| Дистиллированная база знаний | 29 заметок, написанных по кодовой базе сервиса | 100 | Память как конспект: что теряется при сжатии знаний |
| Реальный корпоративный корпус | 68 живых документов компании: контрагенты, договоры, процессы | 50 | Память как есть: документы без адаптации под поиск |
Гибрид «лексика + семантика + связи» находит 88-89% против ручного референса
| Режим поиска | База знаний (100 вопросов) | Корп-корпус (50 вопросов) |
|---|---|---|
| Полнотекстовый (русская морфология) | 71% | 78% |
| Семантический + граф связей | 81% | 80% |
| Гибридный протокол (все вместе) | 88% | 89% |
| Graphiti - открытый движок графа знаний, LLM-экстракция (Qwen2.5-7B, Q4_K_M) | - | 42% (по фактам - 67%) |
Средний hit@5 по трем содержательным категориям вопросов. Сравнение с Graphiti - честное, но с оговоркой: он работал «из коробки» с локальной моделью экстракции Qwen2.5-7B-Instruct (Q4_K_M, Ollama, Apple M3 Max - условие изолированного контура), тогда как наша система - в настроенном виде. Показательна цена: его индексация того же корпуса заняла 2 часа 4 минуты и ~500 обращений к генеративной модели - почти на три порядка дольше наших ≈10 секунд и при нуле таких обращений у нас, и на связанных корпусах это не купило качества.
Проверено на 3600 документах: запись ускорена в 3,7 раза, чтение не деградирует
Чтобы проверить поведение под нагрузкой, мы загрузили открытый корпус из 3600 статей русской Википедии. Исходная реализация содержала на пути записи операции, линейные по числу связей, - из-за этого время записи документа росло с объемом (в 5 раз при росте корпуса в 14 раз), а суммарная загрузка вела себя выраженно сверхлинейно. Анализом планов выполнения рост удалось локализовать до трех запросов сложности O(N) и устранить стандартными средствами СУБД - индексами и переносом нормализации в SQL. После этого запись масштабируется практически линейно: рост времени записи документа сократился с 6,3× до 1,4×, а на 3600 документах полная загрузка ускорилась в 3,7 раза - при полном сохранении семантики связей (число ребер графа совпало до единицы).
| Документов | Полная загрузка (до → после) | Запись, мс/документ (до → после) |
|---|---|---|
| 1000 | 119 с → 62 с | 237 → 124 |
| 2000 | 359 с → 130 с | 359 → 130 |
| 3600 | 880 с → 236 с | 550 → 147 |
Путь чтения при этом не деградирует: полнотекстовый и векторный поиск сохраняют латентность и качество выдачи до 3600 документов и ≈50 000 связей. Мы намеренно сначала измерили деградацию на открытом корпусе, а затем устраняли ее - и показываем обе кривые, а не только финальную.
Четыре вывода, которые переносимы на любую память
Что эти цифры не доказывают
- Вопросы и эталоны готовил один исследователь - общий словарь завышает абсолютные цифры и может влиять даже на относительный порядок режимов. Проверка на независимой разметке - впереди.
- Измерялось качество поиска, а не конечных ответов: «нужный документ в топе» - необходимое, но не достаточное условие правильного ответа.
- Качество измерялось на корпусах в десятки документов; масштаб проверялся отдельно - до 3600 документов и ≈50 000 связей: запись переведена в линейный режим, чтение не деградирует. Поведение на корпусах от десятков до сотен тысяч документов и мультиязычных хранилищах - следующий этап.
Работает внутри FOXOPS, готовится к поставке
Память уже работает внутри FOXOPS: агенты в разработке ПО пишут в нее выводы и достают контекст в новых сессиях; корпоративные документы компании ищутся через тот же контур. Впереди - темпоральный слой фактов («что было верно тогда»), измерение экономии токенов агентных сессий и дистрибутивная реализация для поставки в контур заказчика.
Опубликовано в Zenodo - цитируемый DOI
Рекомендуемое цитирование. Slednev A. Deterministic Long-Term Memory for LLM Agents: Hybrid Retrieval, Document Graph, and Write-Path Scalability in Air-Gapped Environments. Preprint. Version 4.0. July 2026. DOI: 10.5281/zenodo.21210732.
@misc{slednev2026deterministic,
author = {Slednev, Alexandr},
title = {Deterministic Long-Term Memory for LLM Agents: Hybrid Retrieval,
Document Graph, and Write-Path Scalability in Air-Gapped Environments},
year = {2026},
month = jul,
publisher = {Zenodo},
version = {4.0},
doi = {10.5281/zenodo.21210732},
url = {https://doi.org/10.5281/zenodo.21210732}
}