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

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

> **⟶ ЧАСТИЧНО ПЕРЕОПРЕДЕЛЕНО (2026-07-05).** Числа этого дока и рекомендация «SQLite+FTS5+sqlite-vec / эмбеддинги» на ГОРЯЧЕМ пути переопределены: горячий путь детерминированный (Aho-Corasick, НЕ FTS5/не эмбеддинги), числа не переносятся на zh/ja→ru. Актуально: [research/13-memory-bank-validation.md](13-memory-bank-validation.md) + [research/14-adaptive-memory.md](14-adaptive-memory.md) + реестр [architecture/06-memory-risk-registry.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](https://github.com/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](https://github.com/lhl/agentic-memory/blob/main/ANALYSIS-mempalace.md) выявил:

- заявленные 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](https://agentmarketcap.ai/blog/2026/04/10/agent-memory-vendor-landscape-2026-letta-zep-mem0-langmem), [Particula](https://particula.tech/blog/agent-memory-frameworks-tested-mem0-zep-letta-cognee-2026)):

| Система | Суть | Лицензия/статус | Пригодность для «банка памяти книги» |
|---|---|---|---|
| **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](https://github.com/topoteretes/cognee)) | open source | Средняя как референс: их пайплайн «текст→сущности→граф» — образец для автоэкстракции персонажей/локаций, но тянуть весь фреймворк незачем |
| **Memobase** | User-profile память: FastAPI+Postgres+Redis, буферизация записей, фикс. 3 LLM-вызова на flush, ~2.7k звёзд ([GitHub](https://github.com/memodb-io/memobase)) | open source | Низкая: профиль пользователя ≠ лор книги; но паттерн «буфер → отложенный flush в память» хорош для обновления глоссария раз в главу, а не на каждый чанк |

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

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

- **TMX** (Translation Memory Exchange, LISA, актуальная версия 1.4b) — XML-обмен сегментами переводческой памяти; де-факто стандарт обмена между CAT-инструментами ([Wikipedia](https://en.wikipedia.org/wiki/Translation_memory), [Okapi Open Standards](https://okapiframework.org/wiki/index.php/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](https://omegat.org/), [Wikipedia](https://en.wikipedia.org/wiki/OmegaT)). Показателен факт: даже профессиональный CAT-инструмент 20 лет живёт на TSV-глоссариях — это подтверждает выбор простого формата.
- **translate-toolkit** — Python-библиотека с классами для TMX/TBX и конвертерами (`po2tmx`, `csv2tbx`) ([PyPI](https://pypi.org/project/translate-toolkit/), [Wikipedia](https://en.wikipedia.org/wiki/Translate_Toolkit)).

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

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

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

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

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

[GalTransl](https://github.com/GalTransl/GalTransl/blob/main/README_EN.md) (перевод визуальных новелл, 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](https://github.com/SakuraLLM/SakuraLLM) (ja→zh модели для ранобэ/галг): словарь — список `{"src": ..., "dst": ..., "info": ...}`, сериализуется в строки `src->dst #info`, вставляется в user-промпт после фразы «根据以下术语表（可以为空）» («согласно следующему глоссарию (может быть пуст)»). Реализация — [translate_epub.py](https://github.com/SakuraLLM/SakuraLLM/blob/main/translate_epub.py). Важно: модель специально **дообучена следовать глоссарию** — с frontier-моделями то же достигается промптом.

### 3.3 AiNiee и LinguaGacha

- [AiNiee](https://github.com/SakuraLLM/AiNiee-chatgpt) — батч-перевод RPG-игр, EPUB/TXT-новелл, субтитров; та же схема prompt dictionary.
- [LinguaGacha](https://github.com/neavo/LinguaGacha/blob/main/README_EN.md) (zh/en/ja/ko/ru!) — два паттерна, которые стоит скопировать: (1) **one-click автогенерация глоссария** из текста ([wiki](https://github.com/neavo/LinguaGacha/wiki/GlossaryEN)) — имена/локации/организации извлекаются в процессе перевода; (2) **ReTranslation по ключевому слову** ([wiki](https://github.com/neavo/LinguaGacha/wiki/ReTranslationEN)): после правки глоссария находятся все строки с этим термином и пере-переводятся только они. Их мотивация дословно наша: без глоссария «одно имя переводится то в мужском, то в женском варианте».

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

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

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

[SillyTavern World Info](https://docs.sillytavern.app/usage/core-concepts/worldinfo/) — самая проработанная открытая спецификация «активируемой памяти» (годы обкатки на многомесячных ролевых сессиях, т.е. на текстах масштаба книги):

- **Запись:** ключи (регистронезависимые, 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](https://novarrium.com/blog/ai-writing-tools-keep-contradicting-themselves) — тот же паттерн: иерархическая keyword-активируемая база с insertion order, probability и каскадами. [Sudowrite Story Bible](https://docs.sudowrite.com/using-sudowrite/1ow1qkGqof9rtcyGnrWUBS/what-is-story-bible/jmWepHcQdJetNrE991fjJC) — фиксированные поля (Goal, Motivation, Flaw); обзоры отмечают её ригидность против гибкости lorebook. Вывод: **гибкие записи с ключами > жёсткая анкета**, но для персонажей стоит дать шаблон полей поверх гибкой базы.

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

**DelTA** ([arXiv 2410.08143](https://arxiv.org/abs/2410.08143), код [DocMTAgent](https://github.com/YutongWang1216/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](https://arxiv.org/abs/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):

```json
{
  "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](https://aclanthology.org/2024.wmt-1.51/), [Retrieval vs Generation, 2025](https://arxiv.org/pdf/2503.05010), [Dual-Stage Terminology-Aware, 2025](https://arxiv.org/pdf/2511.07461)) сходятся: retrieved-глоссарий в промпте значимо повышает term accuracy, а **мягкое промпт-следование даёт качество выше, чем жёсткий constrained decoding** (который дорог и ломает беглость). Значит: глоссарий в промпт + post-check регэкспом (термин из глоссария передан иначе → флаг редактору/автозамена post-словарём), а не принудительное декодирование.

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

Сравнение алайнеров на литературных корпусах ([Sci. Reports 2023, en-sk](https://www.nature.com/articles/s41598-023-47479-w); [aligner-eval](https://github.com/bfsujason/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](https://academic.oup.com/dsh/article-abstract/38/2/621/6965034) разрабатывался именно на **китайско-английских литературных** параллельных корпусах — наш кейс; 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](https://github.com/asg017/sqlite-vec)** (KNN-поиск; чистый C, zero-dependency, работает через cgo/WASM; v0.1.7, ещё 0.x — вектора держать в отдельной таблице, чтобы миграция на pgvector была тривиальной). Официальный [SQLite Vec1](https://sqlite.org/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 через структурированный вывод.

## Источники

- MemPalace: https://github.com/mempalace/mempalace ; критический разбор: https://github.com/lhl/agentic-memory/blob/main/ANALYSIS-mempalace.md ; фон: https://www.danilchenko.dev/posts/2026-04-10-mempalace-review-ai-memory-system-milla-jovovich/ ; https://arxiv.org/html/2604.21284v1
- Обзоры agent-memory 2026: https://agentmarketcap.ai/blog/2026/04/10/agent-memory-vendor-landscape-2026-letta-zep-mem0-langmem ; https://particula.tech/blog/agent-memory-frameworks-tested-mem0-zep-letta-cognee-2026 ; https://www.graphlit.com/blog/survey-of-ai-agent-memory-frameworks
- Mem0: https://docs.mem0.ai/open-source/overview ; Cognee: https://github.com/topoteretes/cognee ; Memobase: https://github.com/memodb-io/memobase
- Стандарты: https://en.wikipedia.org/wiki/Translation_memory ; https://okapiframework.org/wiki/index.php/Open_Standards ; OmegaT: https://omegat.org/ , https://en.wikipedia.org/wiki/OmegaT ; translate-toolkit: https://pypi.org/project/translate-toolkit/ , https://en.wikipedia.org/wiki/Translate_Toolkit
- Фан-MTL: GalTransl: https://github.com/GalTransl/GalTransl/blob/main/README_EN.md ; SakuraLLM: https://github.com/SakuraLLM/SakuraLLM , https://github.com/SakuraLLM/SakuraLLM/blob/main/translate_epub.py ; AiNiee: https://github.com/SakuraLLM/AiNiee-chatgpt ; LinguaGacha: https://github.com/neavo/LinguaGacha/blob/main/README_EN.md , https://github.com/neavo/LinguaGacha/wiki/GlossaryEN , https://github.com/neavo/LinguaGacha/wiki/ReTranslationEN
- Lorebook/Story Bible: https://docs.sillytavern.app/usage/core-concepts/worldinfo/ ; https://docs.sudowrite.com/using-sudowrite/1ow1qkGqof9rtcyGnrWUBS/what-is-story-bible/jmWepHcQdJetNrE991fjJC ; https://novarrium.com/blog/ai-writing-tools-keep-contradicting-themselves
- Документный/литературный перевод: DelTA: https://arxiv.org/abs/2410.08143 , https://github.com/YutongWang1216/DocMTAgent ; TransAgents: https://arxiv.org/abs/2405.11804
- Терминология в MT: https://aclanthology.org/2024.wmt-1.51/ ; https://arxiv.org/pdf/2503.05010 ; https://arxiv.org/pdf/2511.07461 ; https://arxiv.org/pdf/2310.14451
- Выравнивание: https://www.nature.com/articles/s41598-023-47479-w ; https://academic.oup.com/dsh/article-abstract/38/2/621/6965034 ; https://github.com/bfsujason/aligner-eval
- Хранилище: https://github.com/asg017/sqlite-vec ; https://sqlite.org/vec1 ; https://marcobambini.substack.com/p/the-state-of-vector-search-in-sqlite
