heaven/textmachine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
textmachine/docs/prompts/done/MEMORY_RESEARCH_SESSION_PROMPT.md

11 KiB
Raw Blame History

Промт для сессии «Валидация банка памяти» (черновик от полигона)

Скопируй в новую сессию 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).