Skip to content

После этого Pull request муж вцепился зубами в стол и рычал #81

@neteraf0

Description

@neteraf0

Привет!

Хочу предложить переработку memory-системы. Посмотрел текущую реализацию (mem_zero_memory) - она решает базовую задачу, но по сути это заглушка.

Что сейчас: flat-список воспоминаний, один путь retrieval (semantic search по последнему сообщению, top-5), бесконечное накопление без lifecycle. По сути - append-only лог с cosine similarity.

Проблемы, которые это создаёт при масштабировании:

  1. Шум при росте - чем больше воспоминаний, тем хуже precision. У пользователя с историей в 500+ взаимодействий top-5 семантический поиск начинает тащить нерелевантные результаты - нет механизма ранжирования по важности или свежести.
  2. Один вектор запроса - поиск идёт только по тексту последнего сообщения. Если пользователь спрашивает "продолжай работу над проектом", retrieval ничего полезного не найдёт - нужен контекст из диалога, а не одна строка.
  3. Нет жизненного цикла - воспоминания не обобщаются, не затухают, не усиливаются при повторном использовании. Со временем хранилище засоряется одноразовыми фактами.
  4. Одна гранулярность - "пользователь просил сделать лендинг" и "пользователю нравится тёмная тема" хранятся одинаково, хотя это принципиально разные типы информации с разным временем жизни.

Что предлагаю:

  • Атомарная декомпозиция : при сохранении разбивать взаимодействие на отдельные единицы: факт, предпочтение, задача, контекст. Каждая единица - отдельная запись с типом и метаданными, а не сырой текст диалога.
  • Multi-path retrieval : параллельный поиск по нескольким осям (семантика запроса, извлечённые сущности, текущий контекст диалога) с объединением и дедупликацией. Увеличивает recall без увеличения limit.
  • Lifecycle : decay (снижение веса со временем), strengthening (при повторном использовании), consolidation (обобщение группы похожих воспоминаний водно). По аналогии с тем как работает человеческая память.
  • Pluggable backend : абстракция над хранилищем (mem0, OpenMemoryMCP, локальный SQLite) как инфраструктурная деталь, не как центральная фича.

У меня есть наработки по атомарной декомпозиции и multi-path retrieval - готов адаптировать под архитектуру giga_agent. Начал бы с BaseMemoryAdapter + рефакторинг текущего модуля без потери совместимости, потом расширение.

Что думаете?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions