46 lines
11 KiB
Markdown
46 lines
11 KiB
Markdown
# Промт для сессии «Валидация банка памяти» (черновик от полигона)
|
||
|
||
Скопируй в новую сессию Claude Code, открытую в `/home/ubuntu/projects/textmachine`. Эта сессия — **исследование и валидация**, НЕ реализация: ни строки продуктового кода. Оркестратор финализирует онбординг и место для выходных документов до старта.
|
||
|
||
> _Статус: **финализирован оркестратором (04.07)** на базе черновика полигона. Готов к запуску владельцем._
|
||
|
||
---
|
||
|
||
Ты работаешь над проектом **TextMachine** — AI-перевод крупных художественных текстов (ранобэ/вебновеллы, zh/ja/en→ru) мультиагентным пайплайном на LLM API. Бэкенд — Go, EU-сервер, прямые ключи провайдеров (SaaS, без BYOK).
|
||
|
||
**Контекст (прочитай в этом порядке):**
|
||
- `docs/README.md` — карта проекта; `docs/PROGRESS.md` — журнал (секции «Бэкенд», «Полигон», сообщения оркестратора).
|
||
- `docs/architecture/01-decisions.md` — решение **Р3 «Банк памяти книги»** (это твой предмет) и Р7 (гейты качества).
|
||
- `docs/architecture/05-decisions-log.md` — **D7 (скоуп схемы памяти v1)** и **D5.2** (критично: `snapshotID` обязан покрывать состояние памяти + сборку контекста, иначе изменённая память меняет request_hash, но не snapshotID → resume молча промахивается мимо чекпоинта и переоплачивает расходящимся переводом — валидируй этот инвариант как часть робастности).
|
||
- `docs/research/05-memory-glossary.md` — исследовательская база банка памяти (выбор стека, разбор MemPalace, спека SillyTavern World Info, память DelTA, GalTransl).
|
||
- `docs/architecture/04-unhappy-paths.md` — карта режимов отказа; разделы про консистентность (§1), род/пол (§2, поле gender=hidden), регистры (§3) — банк памяти обслуживает их.
|
||
- `backend/internal/store/` — как банк памяти уже начал реализовываться (схема, миграции) — валидировать против реального кода, а не только доков.
|
||
|
||
**Координация (важно — читай перед стартом):** бэкенд-сессия параллельно строит Фазу 1, и её шаг «миграция памяти v2» (фиксация схемы store/глоссария) **держится до выхода твоего реестра рисков** — ты гейтишь этот шаг. Бэкенд тем временем идёт по runner-loop / snapshotID / чанкеру (шаги 1–3, от схемы памяти не зависят). Твой реестр — вход, по которому бэкенд фиксирует схему; не тяни бесконечно, но и не пропусти опасные сценарии. Синхронизация — через `docs/PROGRESS.md` (заведи секцию `## Память`).
|
||
|
||
**Твоя роль и мандат.** Банк памяти/глоссарий — **главная точка отказа пайплайна** (явное опасение владельца): серверные модели сильны, но если retrieval вернёт пусто или мусор — весь перевод деградирует тихо и опасно. Твоя задача — **адверсариально провалидировать подход до того, как он застынет в коде**: не поверить в него, а попытаться сломать, найти опасные функциональные и технические сценарии, и дать конкретные рекомендации.
|
||
|
||
**Метод.** Многоагентный ресёрч (как исходная фаза research/): фан-аут по направлениям + адверсариальная верификация находок + синтез. Источники — **научные и технические статьи, первоисточники, бенчмарки**; **не покупаться на вендор-маркетинг** (Mem0/Zep/Letta/MemPalace и т.п. — их заявленные метрики проверять независимо, как уже сделано с MemPalace в research/05). Веб + чтение кода; код продукта НЕ писать.
|
||
|
||
**Вопросы, на которые нужен ответ (приоритетно):**
|
||
|
||
1. **Робастность retrieval — центральный вопрос.** Что происходит, когда поиск по банку памяти возвращает пусто / мало / низко-уверенно / нерелевантно? Как это делают зрелые RAG/agent-memory системы (fallback, пороги уверенности, «лучше ничего, чем мусор»)? Спроектируй поведение пайплайна при пустом/слабом retrieval так, чтобы деградация была **явной и безопасной**, а не тихой.
|
||
|
||
2. **Адекватность стека под масштаб.** Выбор research/05: SQLite + FTS5 + sqlite-vec (в MVP — brute-force KNN без C-расширений), эмбеддинги bge-m3. Держит ли это вебновеллу в тысячи записей глоссария × сотни глав? Когда brute-force KNN ломается по латентности/качеству? Где порог перехода на настоящий векторный слой (pgvector/Qdrant/…)? Триггеры миграции — конкретно.
|
||
|
||
3. **Правильность самой задачи retrieval.** «Дан чанк → найди релевантные записи глоссария/резюме». Чистый dense-эмбеддинг — это оптимум, или нужен **гибрид** (BM25/FTS ключи + dense + reranker)? Спека предполагает ключи SillyTavern (лексические) + семантику + двуязычные резюме DelTA. Провалидируй гибрид против литературы по retrieval/reranking.
|
||
|
||
4. **Специфические для перевода режимы отказа** (сломай их): устаревшие записи; спойлер-окно (since_ch/until_ch); **противоречивые записи** (термин перевели двумя способами); разрешение алиасов; **ретрив не того смысла** (омонимы/полисемия имён — 阿Q, 送灶); дрейф «термин → утверждённый перевод» по ходу книги. Как каждый ломает перевод и чем защищаться (детерминированный слой vs LLM в горячем пути).
|
||
|
||
5. **Гарантия детерминизма реестра.** Трёхслойная защита GalTransl (pre-replace нормализация → мягкий глоссарий в промпте → post-check) — провалидируй против исследований constrained decoding / soft-following (WMT). Где грань «жёстко нельзя / мягко можно».
|
||
|
||
6. **Академическое заземление.** DelTA (Proper Noun Records + двуязычные резюме, заявленные +4.58 п.п. консистентности имён / +3.16 COMET) — воспроизводимо ли, на чём мерено, применимо ли к zh/ja→ru? Литература по document-level MT memory, RAG-failure, long-context consistency. Отдельно — свежие работы 2025–2026.
|
||
|
||
**Выход (пути финализированы оркестратором):**
|
||
- `docs/research/13-memory-bank-validation.md` — вердикт: держит ли подход, что менять, с обоснованием и источниками.
|
||
- `docs/architecture/06-memory-risk-registry.md` — **реестр рисков банка памяти** (таблица: сценарий отказа → вероятность/тяжесть → механизм защиты → детерминированный слой vs LLM → где в коде/схеме). Это единственный файл в `architecture/`, который тебе разрешено создать; он — вход для бэкенд-сессии перед фиксацией схемы store/глоссария Фазы 1.
|
||
- Краткие итоги — в `docs/PROGRESS.md` секция `## Память` (1–2 строки на находку + ссылка); каждое расхождение с research/05 или Р3/Р7 — отдельным пингом оркестратору там же.
|
||
|
||
**Эмбеддинги (мандат этой сессии, вопросы 2–3).** Замер bge-m3 vs Qwen3-Embedding-0.6B vs LaBSE на задаче retrieval глоссария/резюме — за тобой. bge-m3 уже на локальном стенде (см. `docs/experiments/03-local-stand.md` и память проекта про стенд); скоординируйся с полигоном, чтобы не дублировать инфраструктуру. Эмпирические скрипты для этого — в `eval/` (это eval, не продуктовый код), результаты — в свой `research/13-*` + краткое в experiments, если полигон попросит.
|
||
|
||
**Правила.** Не редактируй `research/*` и `architecture/*`, КРОМЕ создания своих `research/13-memory-bank-validation.md` и `architecture/06-memory-risk-registry.md` — прочие расхождения оформляй пингами оркестратору в PROGRESS. Фиксируй версии/даты. **Продуктовый код (`backend/`) не пиши — только читай**; eval-скрипты в `eval/` для эмпирической проверки retrieval/эмбеддингов — можно. Маркетинговые метрики вендоров — проверять независимо (как с MemPalace).
|