Архитектура памяти AURA: как инженер увидел систему изнутри

Коллега разобрал нашу архитектуру «на винтики» и точно описал четыре ключевых механизма: halfLife по scope, композитный скоринг, agentic классификацию и cross-role recall. В конце спросил: какие 6 ролей и вокруг какого бизнес-кейса это построено. Отвечаем.

HalfLife по scope: зачем и как

Проблема: все знания не могут жить вечно с одинаковым весом. Новость про рост ставок по ипотеке недельной давности должна весить меньше, чем закон 115-ФЗ, написанный год назад.

Решение: каждому scope присвоен свой период полураспада:

• /news, /market — 90 дней (быстро устаревает)
• /objections, /scripts — 730 дней (методики продаж)
• /regulations, /rules — 3650 дней (законы и этика)
• /precedents — 365 дней (прецеденты Mentor)

Дополнительно: recency floor 0.05 — даже через 10 лет recency не падает до нуля. Статью «почему в июне 2026 выросли цены» можно найти по прямому вопросу через семантику.

Композитный скоринг: α·semantic + β·recency + γ·importance

Когда стажёр задаёт вопрос, система не идёт в базу вслепую. Она вычисляет score для каждой записи:

score = α·semantic + β·recency + γ·importance

• α = 0.5 — вес смыслового сходства (косинус эмбеддингов)
• β = 0.3 — вес свежести (экспоненциальный спад через halfLife)
• γ = 0.2 — вес важности (0..1, назначается автоматически)

Коэффициенты настраиваются через регуляторы — их можно менять под конкретное агентство. Для одних важнее точность, для других — свежесть.

Agentic классификация: что искать под каждый запрос

Модель сама решает, какие источники ей нужны. Не pipeline, а классификатор:

• rules — всегда (этика, 115-ФЗ, комиссия 3%)
• documents — если запрос про договор, шаблон, инструкцию
• knowledge — если про цену, возражение, рынок, клиента
• mentor — если «как быть», «что делать», «были ли прецеденты»
• internet — если новости, тенденции, актуальные данные

Никакого линейного перебора всех слоёв. Только то, что нужно под конкретный запрос.

6 ролей: мультиагентная система

Коллега спросил — отвечаем. AURA — это не один чат-бот, а система из шести агентов, каждый со своей ответственностью:

Шесть ролей — шесть SQLite-баз, одна общая память через engine.js. Cross-role recall работает на всех уровнях: Mentor решил — Colleague знает. Teacher настроил ручки — Colleague применяет.

Бизнес-кейс: агентство недвижимости

Вся эта архитектура построена вокруг одной конкретной задачи: накопление и передача знаний агентства недвижимости.

Проблема: стажёр приходит, учится полгода, начинает продавать — и уходит. Его опыт теряется. Следующий начинает с нуля. Владелец агентства платит за обучение дважды: когда обучает и когда уходит обученный.

AURA решает это через внешнюю память бизнеса:

• Каждый диалог стажёра с Colleague → запись в colleague.sqlite
• Каждое решение Mentor → прецедент в mentor.sqlite
• Каждая найденная Researcher информация → знание в knowledge/
• Каждая оценка Teacher → профиль обучения в teacher.sqlite

Через год работы — это база знаний ~несколько десятков гигабайт. Весь опыт агентства, который не уходит с увольнением.

Выводы

1. Инженерный анализ подтвердил: AURA спроектирована как система долговременной памяти для мультиагентной экосистемы, а не как «чат-бот с историей».
2. Шесть ролей и cross-role recall — ключевое отличие от монолитных AI-ассистентов, включая Titans и Mem0.
3. Бизнес-кейс (агентство недвижимости) — конкретная вертикаль, где проблема утечки знаний стоит острее всего. Но архитектура не привязана к вертикали — те же механизмы применимы к любому бизнесу, где есть текучка кадров и накопление экспертизы.

← Исследование рынка систем памяти