Память: концепция и измеренные результаты
Мы строим долговременную память для команд и их агентов: знания живут в человекочитаемых документах, поверх — поисковый индекс, семантика и граф связей. Здесь — сама концепция и то, что мы намерили, когда проверили её на двух корпусах против ручной валидации по первоисточникам и на открытом корпусе в тысячи документов.
Три принципа, на которых стоит память
Всё работает в изолированном контуре заказчика: ни документы, ни векторы, ни запросы не покидают периметр.
Граница генеративности: детерминированный слой и агент
Языковая модель работает только у агента-читателя, который формирует ответ. Весь путь записи и производные индексы детерминированы: источник истины хранится побайтно, а индекс полностью перестраивается из него переиндексацией. Именно это отличает подход от систем памяти на 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: агенты в разработке ПО пишут в неё выводы и достают контекст в новых сессиях; корпоративные документы компании ищутся через тот же контур. Впереди — темпоральный слой фактов («что было верно тогда»), измерение экономии токенов агентных сессий и дистрибутивная реализация для поставки в контур заказчика.