heaven/textmachine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
textmachine/docs/research/05-memory-glossary.md

40 KiB
Raw Permalink Blame History

Память и глоссарий для консистентного перевода книги: технологии, стандарты, паттерны

Дата исследования: 2026-07-04. Все URL проверены поиском/чтением на дату исследования.

⟶ ЧАСТИЧНО ПЕРЕОПРЕДЕЛЕНО (2026-07-05). Числа этого дока и рекомендация «SQLite+FTS5+sqlite-vec / эмбеддинги» на ГОРЯЧЕМ пути переопределены: горячий путь детерминированный (Aho-Corasick, НЕ FTS5/не эмбеддинги), числа не переносятся на zh/ja→ru. Актуально: research/13-memory-bank-validation.md + research/14-adaptive-memory.md + реестр architecture/06-memory-risk-registry.md. Оставлен как первоисточник обоснований.

TL;DR

  1. "MemPalace" существует — это реальный open-source проект (апрель 2026, ~57k звёзд GitHub, MIT, Python + ChromaDB), но независимый разбор показал разрыв «маркетинг vs код»: бенчмарк-цифры фактически измеряли дефолтные эмбеддинги ChromaDB, часть заявленных фич отсутствует в коде. Форкать не стоит; полезно заимствовать идеи (иерархия Wings→Rooms→Drawers, «пробуждение» за ~170 токенов).
  2. Все agent-memory фреймворки (Letta/MemGPT, Mem0, Zep, LangMem, Cognee, Memobase) заточены под память чат-агента о пользователе, а не под «банк памяти книги». Они Python-first (у нас Go), извлекают «атомарные факты» LLM-вызовами (дорого, недетерминированно) и не дают нужной нам структуры «термин→утверждённый перевод». Вердикт: не форкать, строить своё.
  3. Самый зрелый и прямо применимый паттерн — lorebook / World Info из SillyTavern и NovelAI: записи с ключевыми словами, активируемые только когда ключ встречается в скользящем окне текста, с токен-бюджетом, приоритетами, рекурсией и опциональным embedding-матчингом. Это готовая спецификация нашего «банка памяти».
  4. Фан-MTL-пайплайны (GalTransl, SakuraLLM, AiNiee, LinguaGacha) уже решили консистентность имён дёшево: TSV/JSON-глоссарий src → dst #note, инъецируемый в промпт только для терминов, встречающихся в текущем чанке + pre/post-словарь замен + автогенерация глоссария + точечный ре-перевод строк после правки глоссария.
  5. Академическое подтверждение архитектуры: DelTA (arXiv 2410.08143, Apache-2.0) — агент документного перевода с 4-уровневой памятью (Proper Noun Records, Bilingual Summary, Long/Short-Term Memory) даёт +4.58 п.п. консистентности (LTCR-1) и +3.16 COMET; TransAgents (arXiv 2405.11804, TACL) — мультиагентный литературный перевод с «translation guidelines» (аналог story bible), переводы которого читатели предпочитают GPT-4 и даже человеческим референсам.
  6. Исследования по терминологии (WMT-задачи): мягкая инъекция глоссария в промпт работает лучше жёсткого constrained decoding — гибкое, контекстное следование терминам даёт более высокое качество, чем принудительная подстановка.
  7. Для выравнивания оригинал↔перевод лучший инструмент — Bertalign (F1≈0.987 против 0.979 у Vecalign и 0.900 у hunalign; создан специально для zh↔en литературных корпусов, LaBSE-эмбеддинги покрывают все наши языки).
  8. Рекомендация: SQLite (+FTS5 + sqlite-vec) как хранилище, свой lorebook-механизм активации по ключам как основной путь (детерминированный и бесплатный), эмбеддинги как вторичный; TMX/TBX — только как импорт/экспорт для профессиональной аудитории.

1. «MemPalace» и agent-memory фреймворки

1.1 MemPalace — существует, но форкать не надо

Пользователь не ошибся именем: MemPalace — реальный проект, запущен в апреле 2026, ~47k звёзд за первые две недели (сейчас ~57k заявлено в README), медийное лицо — Milla Jovovich, фактический автор — Ben Sigman. Технически: Python 3.9+, MIT, поверх ChromaDB (плагинно — SQLite, Qdrant, pgvector), эмбеддинги embedding-gemma-300m (мультиязычная, 100+ языков) или all-MiniLM-L6-v2. Архитектура — «дворец памяти»: Wings (люди/проекты) → Rooms (темы) → Drawers (дословный текст); поиск скопированный, а не по плоскому корпусу. Запись без LLM-вызовов (regex + keyword scoring), «пробуждение» контекста ~170 токенов, есть MCP-сервер с 35 инструментами.

Критический разбор lhl/agentic-memory выявил:

  • заявленные 96.6% R@5 на LongMemEval фактически измеряют дефолтные эмбеддинги ChromaDB, а не «дворцовую» структуру;
  • «30x compression with zero information loss» опровергнут: сжатие AAAK роняет качество с 96.6% до 84.2%;
  • «contradiction detection» из README в коде отсутствует; графовые фичи — плоские triple-lookup без обхода графа; нет дедупликации и механизмов забывания;
  • на момент разбора — 7 коммитов, 4 тест-файла на 21 модуль; вердикт разборщика: «NOT PROMOTED», ранний код при отполированном маркетинге. Мейнтейнеры позже сами заменили заголовочные 100%/96.6% на 98.4% на held-out данных и убрали некорректные сравнительные таблицы.

Ценное для TextMachine: иерархическая скопированная адресация памяти, бюджетирование токенов при загрузке, zero-LLM write-pipeline. Как кодовая база — не подходит (Python, chat-memory-ориентация, незрелость).

1.2 Сравнение agent-memory фреймворков

По сводным обзорам 2026 (AgentMarketCap, Particula):

Система Суть Лицензия/статус Пригодность для «банка памяти книги»
Letta (MemGPT) «ОС для памяти»: core (in-context) / recall (история) / archival (векторное хранилище), агент сам управляет памятью Apache-2.0, self-host Низкая: серверный Python-фреймворк вокруг чат-агента; наш случай — batch-пайплайн
Mem0 LLM-экстракция «атомарных фактов» + векторный поиск; ~47k звёзд, $24M Series A; self-reported 94.4% LongMemEval при ~6 787 токенах на запрос Apache-2.0 (OSS — только векторный слой; граф — в платном Pro) Низкая: парадигма «дистилляция фактов» противоположна нашей потребности в дословных, детерминированных решениях («Сяо Янь = Сяо Янь всегда»); каждый write — LLM-вызовы
Zep (Graphiti) Темпоральный граф знаний с окнами валидности фактов; 63.8% LongMemEval (GPT-4o) vs 49.0% у Mem0 на temporal-задачах Graphiti — open source Средне-низкая: темпоральность («X был жив до гл. 120») концептуально полезна для спойлер-контроля, но стек тяжёлый (Neo4j и пр.)
LangMem SDK LangChain: episodic/semantic/procedural память OSS, Python/JS Низкая: привязка к LangChain, у нас Go
Cognee Пайплайн entity extraction → knowledge graph + векторы, self-hosted (GitHub) open source Средняя как референс: их пайплайн «текст→сущности→граф» — образец для автоэкстракции персонажей/локаций, но тянуть весь фреймворк незачем
Memobase User-profile память: FastAPI+Postgres+Redis, буферизация записей, фикс. 3 LLM-вызова на flush, ~2.7k звёзд (GitHub) open source Низкая: профиль пользователя ≠ лор книги; но паттерн «буфер → отложенный flush в память» хорош для обновления глоссария раз в главу, а не на каждый чанк

Общий вывод: вся категория решает задачу «что чат-бот помнит о пользователе между сессиями». Наша задача — иная: детерминированный, редактируемый человеком реестр терминов + иерархический контекст сюжета. Совпадение только на уровне идей.

2. Классические TM/терминологические стандарты: что переиспользовать

  • TMX (Translation Memory Exchange, LISA, актуальная версия 1.4b) — XML-обмен сегментами переводческой памяти; де-факто стандарт обмена между CAT-инструментами (Wikipedia, Okapi Open Standards).
  • TBX (TermBase eXchange, ISO 30042) — обмен терминологическими базами, поддерживает богатую лексическую информацию (часть речи, определение, статус утверждения).
  • XLIFF (OASIS) — формат обмена задачами локализации: пары source/target по сегментам, статусы, комментарии.
  • OmegaT — зрелый (с 2002) open-source CAT на Java (GPL): TMX-память, глоссарии — простые tab-delimited UTF-8 .txt (+ поддержка TBX) (omegat.org, Wikipedia). Показателен факт: даже профессиональный CAT-инструмент 20 лет живёт на TSV-глоссариях — это подтверждает выбор простого формата.
  • translate-toolkit — Python-библиотека с классами для TMX/TBX и конвертерами (po2tmx, csv2tbx) (PyPI, Wikipedia).

Что переиспользовать: не внутреннее хранилище (XML-стандарты избыточны и не содержат наших полей — пол персонажа, стиль речи, спойлер-границы), а импорт/экспорт. Для целевого рынка ru/en-переводчиков совместимость «выгрузил TMX/TBX → открыл в OmegaT/Trados» — прямое конкурентное преимущество и признак «профессионального» продукта. Экспорт в TMX предельно прост (плоский XML); Go-библиотеки тривиально пишутся руками, эталонная реализация для сверки — translate-toolkit.

Классическая TM-механика (fuzzy match по сегментам «уже переводили похожее — вот прошлый перевод») для художественного перевода менее ценна, чем терминология, но пригодится для повторяющихся формул (системные сообщения в LitRPG, повторяющиеся заклинания, эпиграфы).

3. Как фан-MTL-пайплайны решают консистентность (проверенные примеры)

Это самый практичный корпус опыта — сотни тысяч реально переведённых глав.

3.1 GalTransl — эталон «GPT-словаря»

GalTransl (перевод визуальных новелл, GPT-4/Claude/Deepseek/Sakura):

  • Формат словаря: TSV источник \t перевод \t пояснение, например フラン Flan name, lady, teacher. Пояснение — тип, пол, роль, стиль.
  • Селективная инъекция: «только когда имя или предложение, отправляемое GPT в этот раз, содержит это слово, пояснение будет отправлено в этот раунд» — т.е. relevance-фильтр по вхождению подстроки в чанк. Это ровно lorebook-механика.
  • Три типа словарей: pre-translation (детерминированный find-replace в исходнике до LLM — нормализация написаний), post-translation (замены после LLM), условный словарь с логикой judgment word (!, [or], [and]) — замена только при выполнении условия, защита от ложных срабатываний.
  • Кэш перевода с полями pre_zh (черновой перевод) / proofread_zh (вычитанный) — позволяет пере-переводить точечно. Отдельно ведётся name table (фамилия и имя — отдельными строками).

3.2 SakuraLLM — минимальный формат gpt_dict

SakuraLLM (ja→zh модели для ранобэ/галг): словарь — список {"src": ..., "dst": ..., "info": ...}, сериализуется в строки src->dst #info, вставляется в user-промпт после фразы «根据以下术语表（可以为空）» («согласно следующему глоссарию (может быть пуст)»). Реализация — translate_epub.py. Важно: модель специально дообучена следовать глоссарию — с frontier-моделями то же достигается промптом.

3.3 AiNiee и LinguaGacha

  • AiNiee — батч-перевод RPG-игр, EPUB/TXT-новелл, субтитров; та же схема prompt dictionary.
  • LinguaGacha (zh/en/ja/ko/ru!) — два паттерна, которые стоит скопировать: (1) one-click автогенерация глоссария из текста (wiki) — имена/локации/организации извлекаются в процессе перевода; (2) ReTranslation по ключевому слову (wiki): после правки глоссария находятся все строки с этим термином и пере-переводятся только они. Их мотивация дословно наша: без глоссария «одно имя переводится то в мужском, то в женском варианте».

Синтез для TextMachine: трёхслойная схема GalTransl (pre-replace → glossary-in-prompt → post-replace) + автогенерация глоссария при первом проходе + точечный ре-перевод при правке термина = проверенный на практике минимум.

4. Паттерны длинного контекста

4.1 Lorebook / World Info — зрелый паттерн, копировать целиком

SillyTavern World Info — самая проработанная открытая спецификация «активируемой памяти» (годы обкатки на многомесячных ролевых сессиях, т.е. на текстах масштаба книги):

  • Запись: ключи (регистронезависимые, regex, списки), вторичные ключи с логикой AND ANY / AND ALL / NOT ANY / NOT ALL, контент, заголовок-мемо.
  • Активация: по вхождению ключа в последние N сообщений (scan depth); режимы: constant (всегда), keyed (по ключу), vectorized (по embedding-близости) — все три нам нужны.
  • Бюджет: жёсткий токен-лимит на все активированные записи (абсолютный или % от контекста); при исчерпании новые записи не вставляются; порядок — сначала constant, затем по insertion order.
  • Рекурсия: активированная запись может активировать другие (упоминание «Академия Тьмы» подтягивает запись об академии), с ограничителем max recursion steps и флагами non-recursable/prevent recursion.
  • Timed effects: sticky (запись остаётся активной N сообщений), cooldown, delay — для перевода это «инерция сцены»: персонаж вошёл в сцену — его карточка держится несколько чанков, даже если имя не повторяется (местоимения!).
  • Inclusion groups: конкурирующие записи (напр., «Ким до таймскипа» vs «Ким после») — выбирается одна по весу/приоритету.

NovelAI Lorebook — тот же паттерн: иерархическая keyword-активируемая база с insertion order, probability и каскадами. Sudowrite Story Bible — фиксированные поля (Goal, Motivation, Flaw); обзоры отмечают её ригидность против гибкости lorebook. Вывод: гибкие записи с ключами > жёсткая анкета, но для персонажей стоит дать шаблон полей поверх гибкой базы.

4.2 Академические подтверждения: DelTA и TransAgents

DelTA (arXiv 2410.08143, код DocMTAgent, Apache-2.0) — документный перевод с 4-уровневой памятью:

  1. Proper Noun Records — реестр «встреченное имя собственное → его первый перевод», при повторе то же переводное соответствие принудительно переиспользуется (наш глоссарий, автопополняемый);
  2. Bilingual Summary — двуязычное резюме источника и перевода (жанр, суть) — наш rolling summary;
  3. Long-Term Memory — retrieval релевантных предложений по всему документу;
  4. Short-Term Memory — последние предложения как few-shot контекст.

Результат: консистентность (LTCR-1) +4.58 п.п., COMET +3.16 против сильных baseline на 4 LLM. Это прямое экспериментальное доказательство главной ставки TextMachine: структурированная память > длинный контекст.

TransAgents (arXiv 2405.11804, принята в TACL) — мультиагентная «переводческая компания» (CEO, Senior/Junior Editor, Translator, Localization Specialist, Proofreader) для ультрадлинных литературных текстов. Ключевое для нас: подготовительная стадия, где до перевода составляются translation guidelines (глоссарий, тон, стиль, аудитория) — формализованный story bible, которым руководствуются все агенты. d-BLEU у системы ниже, но читатели и LLM-оценщики предпочитают её переводы GPT-4 и человеческим референсам.

4.3 Иерархия сцена→глава→арка→книга и RAG

Синтез паттернов (lorebook + DelTA + практика Sudowrite/NovelAI) для книги на 1000+ глав:

  • Rolling summary уровня главы (обновляется после перевода главы, 100–300 токенов) → сворачивается в резюме арки (раз в 20–50 глав) → резюме книги. В промпт чанка идут: резюме книги (сжатое) + текущей арки + текущей главы + хвост предыдущего чанка перевода (стык стиля).
  • RAG по переведённым главам — вторичный механизм: embedding-поиск фрагментов, где термин/сцена встречались ранее (нужен для редких терминов, флешбеков, «как мы тогда перевели это стихотворение»). Именно так работает Long-Term Memory DelTA и vectorized-записи SillyTavern.
  • Спойлер-контроль: записи глоссария должны иметь поле «действительно с главы X» (аналог темпоральности Zep/Graphiti и inclusion groups SillyTavern) — чтобы перевод главы 5 не знал, что «учитель — предатель» из главы 200.

5. Экономия токенов: структура глоссария и отбор записей

5.1 Поля записи

Минимальный формат фан-пайплайнов (src/dst/info) стоит расширить до (наш дизайн, поля подтверждаются практикой GalTransl name tables и Story Bible):

{
  "id": 412, "src": "萧炎", "dst": "Сяо Янь",
  "type": "character",             // character|place|org|item|skill|title|other
  "aliases": ["炎哥", "萧炎哥哥"],  // альтернативные написания в исходнике
  "gender": "m",                    // критично для ru (род глаголов!) и en-местоимений
  "speech": "дерзкий, просторечие; к старшим — на вы",  // стиль речи
  "decl": "Сяо Яня, Сяо Яню",      // словоформы для ru (склонение имён)
  "since_ch": 1, "until_ch": null, // спойлер-окно
  "status": "approved",            // approved | auto | draft
  "note": "гг; 'Янь' не переводить как 'пламя'"
}

Для ru-таргета поля gender, speech и склонения — то, чего нет ни в одном западном инструменте и что напрямую бьёт по «нехудожественности» (несогласованный род — типовой провал MTL с zh/ja, где род не маркирован).

5.2 Токен-бюджет инъекции (оценки)

В промпт сериализуется компактная строка вида 萧炎 -> Сяо Янь #персонаж, м, дерзкий (формат SakuraLLM). Оценка: 10–30 токенов на запись (CJK-имя + русский перевод + короткая заметка). Отсюда:

  • полный глоссарий книги (500–2000 записей) целиком — 10–50k токенов на каждый вызов: неприемлемо;
  • селективная инъекция (только термины, чьи src/aliases встречаются в чанке 1–3k токенов): типично 5–30 записей = 100–800 токенов, т.е. 5–25% размера чанка — приемлемая наценка, у дешёвых моделей это доли цента;
  • контраст-ориентир: Mem0 тратит ~6 787 токенов на запрос при LLM-экстракции памяти — наш детерминированный отбор на порядок дешевле.

Механика отбора (по образцу GalTransl/SillyTavern, без LLM и без эмбеддингов в горячем пути): для zh/ja — поиск подстроки (пробелов нет, работает надёжно); для en/ru — сопоставление по словоформам (для ru — леммы или заготовленные decl); + «инерция сцены» (sticky): персонажи, активные в предыдущих 1–2 чанках, остаются в глоссарии текущего (местоимения без имени). Токен-бюджет с приоритетами (approved > auto; персонажи чанка > фоновые) — как в World Info.

5.3 Дешёвое автопополнение

Автоэкстракцию новых терминов вешать не на отдельный дорогой вызов, а на тот же вызов переводчика (доп. поле структурированного вывода: «новые имена собственные в этом чанке и предложенный перевод»), с последующим batch-подтверждением судьёй/человеком раз в главу — паттерн буферизации как у Memobase. Исследования WMT (Efficient Terminology Integration, WMT 2024, Retrieval vs Generation, 2025, Dual-Stage Terminology-Aware, 2025) сходятся: retrieved-глоссарий в промпте значимо повышает term accuracy, а мягкое промпт-следование даёт качество выше, чем жёсткий constrained decoding (который дорог и ломает беглость). Значит: глоссарий в промпт + post-check регэкспом (термин из глоссария передан иначе → флаг редактору/автозамена post-словарём), а не принудительное декодирование.

6. Выравнивание чанков оригинал↔перевод

Сравнение алайнеров на литературных корпусах (Sci. Reports 2023, en-sk; aligner-eval):

Инструмент Подход F1
Bertalign эмбеддинги LaBSE (мультиязычные, ~100+ языков) 0.987
Vecalign эмбеддинги LASER + рекурсивный DP 0.979
Bleualign через MT-перевод 0.911
hunalign словарь + Gale-Church (длины) 0.900
Gale-Church только длины 0.852

Bertalign разрабатывался именно на китайско-английских литературных параллельных корпусах — наш кейс; Python, лицензия открытая (репозиторий bfsujason/bertalign). Поддерживает выравнивания 1-к-многим/многие-к-1 (художественный перевод часто дробит/сливает предложения).

Применения в TextMachine: (1) фронтенд параллельного чтения (подсветка соответствий предложение-к-предложению); (2) валидация полноты перевода (пропущенные предложения — типовой сбой LLM на длинных чанках); (3) построение TM из уже существующих человеческих переводов (импорт пары «оригинал+официальный перевод» → выровняли → готовая память и глоссарий-кандидаты). Заметим: если перевод порождается нашим же пайплайном чанк-за-чанком со структурированным выводом (массив предложений/абзацев), выравнивание получается бесплатно by construction — Bertalign нужен для импорта внешних текстов и восстановления после сбоев. Для дешёвого fallback без GPU — hunalign (C++, быстрый, но нужен словарь и качество ниже).

7. Строить своё или форкать готовое

Строить своё поверх SQLite. Аргументы:

  • Ни один кандидат на форк не совпадает по домену: agent-memory фреймворки — про чат-персонализацию (и Python), MemPalace — незрелый, CAT-инструменты (OmegaT — Java/GPL, монолитный десктоп) — про сегментную TM без художественных полей. Доменная модель (глоссарий со спойлер-окнами, стили речи, иерархические резюме, кэш переводов чанков) — это и есть ядро продукта, его нельзя аутсорсить.
  • Хранилище: SQLite + FTS5 (полнотекст/ключи) + sqlite-vec (KNN-поиск; чистый C, zero-dependency, работает через cgo/WASM; v0.1.7, ещё 0.x — вектора держать в отдельной таблице, чтобы миграция на pgvector была тривиальной). Официальный SQLite Vec1 (v0.7) — запасной вариант. Один файл БД на книгу = простые бэкапы, экспорт, локальная работа.
  • Эмбеддинги локально на 8GB GPU: мультиязычная модель класса bge-m3 / LaBSE покрывает zh/ja/en/ru (LaBSE уже используется Bertalign — можно один стек на выравнивание и RAG) (выбор конкретной модели — проверить бенчмарки MTEB на момент реализации).
  • Горячий путь (отбор записей для чанка) — без LLM и желательно без эмбеддингов: ключи/алиасы/леммы + sticky, как GalTransl и SillyTavern. Эмбеддинг-поиск — второй эшелон (флешбеки, «где это было»). LLM — только для автоэкстракции кандидатов и резюме (батчево, раз в главу).

Выводы для TextMachine

  1. «Банк памяти книги» = lorebook + глоссарий + иерархические резюме, а не agent-memory фреймворк. Копируем спецификацию World Info (ключи, вторичные ключи, токен-бюджет, constant/keyed/vectorized, sticky/cooldown, inclusion groups, рекурсия) как ТЗ на модуль памяти; DelTA подтверждает архитектуру цифрами (+4.58 п.п. консистентности).
  2. MemPalace пользователю показать как «нашли, разобрали, не берём»: реальный, хайповый, но бенчмарки измеряли ChromaDB, фичи из README отсутствуют в коде; заимствуем только идеи иерархии и токен-бюджета «пробуждения».
  3. Схема глоссария: src/dst/type/aliases/gender/speech/decl/since_ch/until_ch/status/note; сериализация в промпт src -> dst #короткая заметка; селективная инъекция по вхождению в чанк + инерция сцены; бюджет ~300–800 токенов на чанк. Поля gender/speech/склонения — наше отличие для ru-рынка.
  4. Трёхслойная защита консистентности (по GalTransl): pre-replace (нормализация исходника) → глоссарий в промпте (мягко) → post-check/post-replace + флаг редактору. Жёсткий constrained decoding не использовать — исследования показывают деградацию качества.
  5. Пайплайн памяти по главам: перевод чанков (STM = хвост перевода) → автокандидаты терминов из того же вызова → batch-подтверждение раз в главу → rolling summary главы → свёртка в арку/книгу. Спойлер-окна у записей обязательны.
  6. Фичи продукта, доказанные конкурентами: автогенерация глоссария одним кликом и точечный ре-перевод всех вхождений после правки термина (LinguaGacha) — must-have; экспорт TMX/TBX и tab-glossary OmegaT — для профессиональной аудитории.
  7. Стек: SQLite + FTS5 + sqlite-vec (Go, cgo), Bertalign (Python-микросервис или порт) для выравнивания импортируемых параллельных текстов и фронта параллельного чтения; выравнивание собственных переводов — by construction через структурированный вывод.

Источники