YantrikDB: «забывающая» база памяти для ИИ‑агентов, которая сама чистит, сжимает и ловит противоречия — VogueTech

Что нового

YantrikDB — это не просто векторное хранилище, а «когнитивный» движок памяти для ИИ‑агентов. Он не только складывает эмбеддинги, но и сам управляет тем, что хранит:

Управляемое забывание
Каждая запись получает важность и период полураспада. Пример:

db.record("read the SLA doc by Friday", importance=0.4, half_life=86400)  # 1 день
# Через 24 часа релевантность заметно падает
# Через 7 дней эта память больше не всплывает в обычном recall, только при прямом запросе

Консолидация памяти
YantrikDB умеет сжимать десятки похожих фрагментов в несколько «канонических» записей:

# 20 похожих заметок про один и тот же митинг
for note in meeting_notes:
    db.record(note, namespace="standup-2026-04-12")

db.think()
# → {"consolidation_count": 5}
# 20 фрагментов схлопнулись в 5 аккуратных воспоминаний

Обнаружение противоречий
Движок сам находит конфликтующие факты:

db.record("CEO is Alice")
db.record("CEO is Bob")  # записано позже в другом диалоге

db.think()
# → {
#   "conflicts_found": 1,
#   "conflicts": [
#     {
#       "memory_a": "CEO is Alice",
#       "memory_b": "CEO is Bob",
#       "type": "factual_contradiction"
#     }
#   ]
# }

Многосигнальная оценка релевантности
При поиске YantrikDB учитывает сразу несколько факторов: близость по эмбеддингу, давность, важность, связи в графе сущностей и прошлый опыт успешных/неудачных выдач.
Измеримая экономия токенов на памяти
Автор показывает сравнение с «файловой» памятью (когда вы просто подсовываете модели один большой файл с прошлым контекстом):

| Кол-во воспоминаний | File-based токенов | YantrikDB токенов | Точность File-based | Точность YantrikDB | |---------------------|--------------------|-------------------|----------------------|---------------------| | 100 | 1 770 | 69 | 66% | 96% | | 500 | 9 807 | 72 | 77% | 99,3% | | 1 000 | 19 988 | 72 | 84% | 99,6% | | 5 000 | 101 739 | 53 | 88% | 99,9% |

При 500 воспоминаниях файл уже не влезает в 32K контекст. При 5 000 — не помещается ни в 32K, ни в 200K. YantrikDB при этом остаётся на уровне ~70 токенов на запрос.
Производительность (из живого стенда)
На кластере LXC с 2 ядрами и 1 689 воспоминаниями:
- median (p50) latency для recall — 112 мс, из них ~100 мс уходит на эмбеддинг запроса;
- p99 для recall — 190 мс;
- пакетная запись — 76 записей в секунду;
- захват блокировки движка — < 0,1 мс;
- глубокий health‑check — < 1 мс.
Если использовать уже посчитанные эмбеддинги и не считать их на запросе, p50 для recall падает примерно до 5 мс.
Статус проекта
Сейчас версия v0.5.11 — «закалённый альфа‑релиз». Встраиваемый движок уже работает в проде в экосистеме YantrikOS с начала 2026 года. Сетевой сервер новее, но уже крутится на трёхузловом Proxmox‑кластере с несколькими арендаторами.

Команда прошла «спринт закалки» из 42 задач в рамках 8 эпиков: от внедрения parking_lot‑мьютексов с детектором дедлоков до хаос‑тестов с убийством лидера и kill -9 посреди записи.
Три способа использования
- как сетевой сервер (Docker, HTTP + бинарный протокол, HA‑кластер 2+1);
- как MCP‑сервер для Claude Code, Cursor, Windsurf;
- как встраиваемая библиотека для Python и Rust.

Как это работает

Базовая идея: не «поиск по эмбеддингам», а живой движок памяти

Обычная схема памяти ИИ выглядит так:

Сохраняем всё подряд.
Считаем эмбеддинги.
Достаём top‑k по косинусному сходству.
Кладём в контекст запроса и надеемся, что модель разберётся.

YantrikDB строит вокруг этого полноценную систему памяти:

иерархичную (семантическая, эпизодическая, процедурная память);
сжимающую (консолидация похожих воспоминаний);
временную (учёт давности и дедлайнов);
эмоционально взвешенную (valence — тон записи);
самообновляющуюся (think() работает «между разговорами»).

Архитектура движка

Движок написан на Rust и работает как встраиваемая база «как SQLite»: один бинарник, один файл на пользователя, без отдельного сервера (если вы не хотите сетевой режим).

Под капотом пять индексов:

┌──────────────────────────────────────────────────────┐
│ YantrikDB Engine                                    │
│                                                      │
│  ┌──────────┬──────────┬──────────┬──────────┐       │
│  │ Vector   │ Graph    │ Temporal │ Decay    │       │
│  │ (HNSW)   │(Entities)│ (Events) │ (Heap)   │       │
│  └──────────┴──────────┴──────────┴──────────┘       │
│                                                      │
│  ┌──────────┐                                        │
│  │ Key-Value│  WAL + Replication Log (CRDT)          │
│  └──────────┘                                        │
└──────────────────────────────────────────────────────┘
``

- **Vector Index (HNSW)** — быстрый поиск по смыслу между воспоминаниями.
- **Graph Index** — граф сущностей и связей: кто с кем связан, какие профили и роли.
- **Temporal Index** — события во времени, запросы вроде «что было во вторник» или «какие дедлайны впереди».
- **Decay Heap** — структура, которая отслеживает, что пора «забывать» или понижать важность.
- **Key‑Value Store** — быстрый доступ к фактам, состоянию сессий и служебным весам.

Все операции потокобезопасны: Rust‑движок реализует `Send + Sync`, использует `Mutex/RwLock` и `parking_lot` с детектором дедлоков.

### Типы памяти по Талвингу

YantrikDB опирается на классификацию памяти Энделя Талвинга и хранит три типа:

- **Семантическая** — факты и знания:  
  `"User is a software engineer at Meta"`
- **Эпизодическая** — события с контекстом:  
  `"Had a rough day at work on Feb 20"`
- **Процедурная** — стратегии и «как лучше делать»:  
  `"Deploy with blue-green, not rolling update"`

Каждое воспоминание несёт с собой:

- importance (важность);
- valence (эмоциональный тон);
- domain (область);
- source (источник);
- certainty (уверенность);
- временные метки.

Все эти сигналы участвуют в итоговой оценке релевантности.

### Многосигнальный recall

При вызове `recall()` движок не ограничивается косинусной близостью эмбеддингов. Он комбинирует:

- **semantic similarity (HNSW)** — по смыслу к запросу;
- **temporal decay** — более свежие воспоминания получают бонус;
- **importance weighting** — важные решения перебивают мелочи;
- **graph proximity** — записи, связанные с теми же сущностями, поднимаются выше;
- **retrieval feedback** — движок подстраивает веса под то, что реально помогало модели в прошлом.

Весовые коэффициенты он учит на основе реального использования.

### Конфликты и консолидация

Функция `think()` — это «ночная уборка» в памяти:

- **Consolidation** — объединяет похожие воспоминания и формирует канонические формулировки.
- **Conflict scan** — ищет противоречащие факты.
- **Pattern mining** — находит пересечения между доменами (например, связь стресса и записей о здоровье).
- **Trigger evaluation** — решает, о чём нужно проактивно напомнить пользователю.

Конфликт движок оформляет явно, с типом и стратегией решения. Пример:

```text
"works at Google" (15 января) vs. "works at Meta" (1 марта)
→ Conflict: identity_fact, priority: high, strategy: ask_user

Идея в том, что агент не молча перезаписывает факт, а задаёт уточняющий вопрос в диалоге.

Локальность и синхронизация

YantrikDB спроектирован как local‑first:

данные живут локально в одном файле;
синхронизация идёт через append‑only лог операций с использованием CRDT;
каждый девайс сам пересобирает HNSW‑индекс по сырым воспоминаниям;
«забывание» распространяется через tombstone‑записи, чтобы удалённое не воскресало на других устройствах;
противоречия между устройствами помечаются и выносятся на разрешение.

Сессии и временная осознанность

Движок понимает, что взаимодействие с агентом идёт сессиями:

sid = db.session_start("default", "claude-code")

db.record("decided to use PostgreSQL")      # автоматически привязано к сессии
db.record("Alice suggested Redis for caching")

db.session_end(sid)
# → считает: количество воспоминаний, средний тон, темы, длительность

# Высоковажные воспоминания, к которым давно не обращались
db.stale(days=14)

# Записи с приближающимися дедлайнами
db.upcoming(days=7)

На основе сессий движок может строить профили, отслеживать прогресс по целям и поднимать забытые, но важные решения.

Что это значит для вас

Когда YantrikDB действительно полезен

Долгоживущие ИИ‑ассистенты
Если вы строите собственного «второго мозга» для пользователя — личный помощник, коуч, терапевтический бот, рабочий ассистент — простого векторного поиска быстро перестаёт хватать. После 10 000 записей качество вспоминания обычно падает: слишком много шума, нет забывания и консолидации.

YantrikDB как раз рассчитан на такой сценарий: он держит размер выдачи около 70 токенов, повышает точность с ростом объёма памяти и сам чистит базу.
Сложные агенты‑разработчики (Claude Code, Cursor, Windsurf)
Через MCP YantrikDB превращается в «внешний мозг» для IDE‑агентов:
- агент автоматически вспоминает прошлые решения по проекту;
- сам сохраняет ключевые решения и архитектурные дискуссии;
- ловит противоречия (например, разные версии решения одной и той же задачи в разных ветках диалога).
Вам не нужно писать промпты вида «помни это» — MCP‑интеграция делает это прозрачно.
Мультидевайс‑сценарии
Если вы хотите, чтобы память агента жила и на ноутбуке, и на телефоне, и на сервере — CRDT‑подход и локальные файлы снимают много боли. Каждый девайс автономен, сеть нужна только для синка.
Продукты с чувствительными данными
Сетевой сервер даёт:
- AES‑256‑GCM шифрование «на диске»;
- per‑tenant квоты;
- метрики Prometheus;
- кластер 2‑voter + 1‑witness через Docker Compose или Kubernetes.
Для внутренних корпоративных ассистентов это полезно: можно поднять кластер в своём периметре и не отправлять память в облачные векторные сервисы.

Когда лучше поискать что‑то попроще

Разовые чат‑боты и лендинги
Если у вас FAQ‑бот с 200 вопросами и без истории пользователя, YantrikDB будет избыточен. Проще взять любой управляемый векторный сервис (Pinecone, Weaviate) или вообще обойтись файлом с контекстом.
Только строгие графы знаний
Если вам нужна чистая онтология с жёсткими схемами и сложными граф‑запросами, Neo4j и другие графовые базы подойдут лучше. YantrikDB умеет граф, но он заточен под «размытые» человеческие воспоминания, а не под корпоративные справочники.
Если вы не готовы жить с альфой
Версия v0.5.11 — уже обкатанная, но формально это всё ещё альфа. Движок прошёл 1 178 core‑тестов, хаос‑харнесс и cargo-fuzz, но критичные банковские сценарии лучше запускать с осторожностью.

Доступность и ограничения

Проект — open source под AGPL‑3.0. MCP‑сервер — под MIT, его использование не распространяет AGPL на ваш код. Отдельных геоограничений автор не указывает, VPN для доступа к репозиторию не нужен. Развёртывание — на вашей инфраструктуре, так что вопрос доступности в России упирается только в доступ к GitHub/ghcr.io и Docker‑образам.

Место на рынке

YantrikDB занимает интересную нишу между векторными БД, графовыми БД и «прослойками памяти» вроде LangChain.

Векторные базы (Pinecone, Weaviate и др.)

Что умеют:

быстрый nearest‑neighbor поиск по эмбеддингам;
масштабирование по шардированию;
управляемый облачный сервис.

Чего там нет:

нет временного распада и понятия «забывания»;
нет причинно‑следственных связей и графа сущностей как гражданина первого класса;
нет фоновой консолидации и конфликтообнаружения.

YantrikDB встраивает HNSW‑поиск внутрь более богатой модели памяти: он не конкурирует напрямую с Pinecone как «облако для эмбеддингов», а заменяет его там, где нужно именно долговременное «мышление» о памяти.

Графовые базы (Neo4j и аналоги)

Плюсы графовых БД:

сильный язык запросов по связям;
удобство для строго структурированных доменов.

Минусы для памяти ИИ:

плохо работают с «размытыми» воспоминаниями и эмбеддингами;
не решают задачу автоматического забывания и сжатия.

В YantrikDB граф — это один из пяти индексов, а не вся история. Он помогает поднимать связанные воспоминания, строить профили и считать близость по сущностям.

Фреймворки памяти (LangChain, Mem0 и др.)

Что они дают:

удобные абстракции для retrieval‑chain;
обёртки над векторными БД, файлами, кешами.

Чего там нет:

собственной архитектуры памяти — это прослойки и glue‑код;
фона, который сам консолидацирует, забывает и ищет конфликты.

YantrikDB можно использовать как backend для таких фреймворков, если вам нужна именно «живая» память под ними.

File‑based подход (CLAUDE.md, большие memory‑файлы)

Как это обычно выглядит:

вы ведёте один или несколько markdown‑файлов с историей пользователя;
на каждом запросе подсовываете их модели целиком или кусками.

Проблемы:

линейный рост токенов: при 5 000 воспоминаний — 101 739 токенов на запрос;
контекст перестаёт помещаться даже в 200K окон;
нет фильтрации по релевантности, модель задыхается от шума.

YantrikDB на тех же 5 000 воспоминаний держит 53 токена в выдаче и повышает точность до 99,9%.

Установка

Как сетевой сервер

Запустить сервер YantrikDB можно одной командой Docker:

docker run -p 7438:7438 ghcr.io/yantrikos/yantrikdb:latest

curl -X POST http://localhost:7438/v1/remember -d '{"text":"hello"}'

Особенности сетевого режима:

один Rust‑бинарник;
HTTP и бинарный wire‑протокол;
HA‑кластер 2 voter + 1 witness через Docker Compose или Kubernetes;
per‑tenant квоты;
метрики Prometheus;
шифрование на диске AES‑256‑GCM;
runtime‑детектор дедлоков.

Для примеров конфигурации есть docker-compose.cluster.yml и манифесты для Kubernetes.

Как MCP‑сервер (Claude Code, Cursor, Windsurf)

Установка:

pip install yantrikdb-mcp

Дальше вы добавляете YantrikDB в конфиг MCP‑клиента. Агент начинает автоматически:

подтягивать релевантный контекст;
сохранять важные решения;
находить противоречия.

Дополнительных промптов не требуется. Подробности — в репозитории yantrikdb-mcp.

Как встраиваемая библиотека (Python или Rust)

Python

pip install yantrikdb

Пример использования:

import yantrikdb
from sentence_transformers import SentenceTransformer

db = yantrikdb.YantrikDB("memory.db", embedding_dim=384)

db.set_embedder(SentenceTransformer("all-MiniLM-L6-v2"))

db.record("Alice leads engineering", importance=0.8)

db.recall("who leads the team?", top_k=3)

db.think()  # консолидация, поиск конфликтов, вывод личности

Rust

cargo add yantrikdb

Дальше вы работаете с Rust‑API, которое даёт те же операции: record, recall, think, индексацию графа и т.д.

Как запустить: API и операции

YantrikDB предлагает не SQL, а «когнитивный» API. Основные группы методов:

Базовые операции

record, record_batch — записать одно или много воспоминаний;
recall, recall_with_response, recall_refine — достать релевантные воспоминания;
forget — забыть запись;
correct — скорректировать память.

Граф знаний

relate — связать сущности;
get_edges — получить связи;
search_entities — поиск по сущностям;
entity_profile — профиль сущности;
relationship_depth — глубина связей;
link_memory_entity — связать память с сущностью.

Когниция

think — запустить консолидацию, поиск конфликтов и паттернов;
get_patterns — получить найденные паттерны;
scan_conflicts — список конфликтов;
resolve_conflict — пометить конфликт решённым;
derive_personality — вывод «личности» на основе паттернов памяти.

Триггеры

get_pending_triggers — список активных триггеров;
acknowledge_trigger, deliver_trigger, act_on_trigger, dismiss_trigger — управление триггерами.

Сессии

session_start, session_end, session_history;
active_session, session_abandon_stale.

Время

stale — важные, но давно не тронутые воспоминания;
upcoming — то, где приближаются дедлайны.

Процедурная память

record_procedural — сохранить стратегию;
surface_procedural — подсветить полезный паттерн;
reinforce_procedural — усилить часто работающую стратегию.

Жизненный цикл

archive, hydrate, decay, evict, list_memories, stats.

Синхронизация

extract_ops_since, apply_ops — выгрузка и применение операций;
get_peer_watermark, set_peer_watermark — маркеры синка.

Обслуживание

rebuild_vec_index, rebuild_graph_index, learned_weights — переиндексация и работа с обученными весами.

Лицензия и развитие

Основной движок YantrikDB распространяется под AGPL‑3.0.
MCP‑сервер — под MIT. Использование YantrikDB через MCP не навешивает AGPL на ваш код.

Автор:

Pranab Sarkar — доступен через ORCID, LinkedIn и по почте developer@pranab.co.in.

Исследования и публикации:

Заявка на патент США 19/573,392 (март 2026): "Cognitive Memory Database System with Relevance-Conditioned Scoring and Autonomous Knowledge Management".
Публикация на Zenodo: "YantrikDB: A Cognitive Memory Engine for Persistent AI Systems".

Дорожная карта (суммарно):

V0 — встраиваемый движок, базовая модель памяти (record, recall, relate, consolidate, decay).
V1 — лог репликации, CRDT‑синк между устройствами.
V2 — разрешение конфликтов с участием человека.
V3 — проактивный когнитивный цикл, паттерны, триггер‑система.
V4 — сессии, временная осознанность, кросс‑доменные паттерны, профили сущностей.
V5 — общая память для нескольких агентов и федеративное обучение между пользователями.

Если вам нужен не просто «поиск по прошлым сообщениям», а долговременная, самоуправляемая память для ИИ‑агента — YantrikDB даёт именно это и уже сейчас работает достаточно быстро, чтобы не быть узким местом в проде.