Land research/19 chunking-cohesion report with sources and archive its executed prompt: emission-window-cohesion split, Go chunker spec, wave architecture, pre-registered Q0-Q5 design
This commit is contained in:
parent
2d9f70bb84
commit
c5171b47c5
3 changed files with 1499 additions and 1 deletions
|
|
@ -1,3 +1,5 @@
|
|||
> **⟶ ОТРАБОТАН (2026-07-16), ЗАЛЕНДЕН D39.1.** Выход: `docs/research/19-chunking-cohesion.md` (+`-sources.md`, 52 клейма: 36 CONFIRMED / 16 OVERSTATED-с-коррекциями, 65-агентный веб-воркфлоу + 5-линзовое само-ревью, 8 MAJOR исправлены до сдачи). Ключевое: конфликт exp14↔research/18 разрешён как ложная дихотомия (эмиссия ≠ окно чтения ≠ единица связности); Go-спека чанкера (профиль→B0–B5→DP) + фоллбек-веер; когезия carryover/lookahead/стейт БЕЗ LLM-summary; **волновая архитектура W0–W3 (вводная владельца 16.07: параллелизм)**; §D пре-рег дизайн Q0–Q5. Оркестратор-ревью НЕ проводилось по решению владельца (сессия отревьюирована своим воркфлоу + сильной моделью). Правки владельца в задаче 1 (роли при чанковании; lost-in-middle) — закрыты §A.1/Q2c. Архивная копия.
|
||||
|
||||
# Промт: сессия-РЕСЁРЧЕР — логическая нарезка + меж-чанковая когезия + дизайн эмпирики (трек B), 2026-07-13
|
||||
|
||||
> Рождён из арх-ресета **D39** (`docs/architecture/05-decisions-log.md`, `09-target-architecture.md` §2 слой 1, §4 трек B). Это **ресёрч ПЕРЕД постройкой** для сцепленных концернов **1 (разделение переводчик/редактор), 2 (нарезка), 4 (частично)**. Ты НЕ пишешь прод-код и НЕ гоняешь платную эмпирику — ты (1) добываешь best-practices, (2) проектируешь реализуемый чанкер+когезию, (3) выдаёшь ПРЕ-РЕГИСТРИРОВАННЫЙ дизайн полигон-эмпирики, которую потом исполнит полигон-сессия.
|
||||
|
|
@ -28,7 +30,9 @@
|
|||
- Инженерные best-practices: recursive/semantic splitting, sentence-window / parent-document, discourse/scene-boundary detection, topic segmentation (TextTiling и потомки), overlap-стратегии — с их РЕАЛЬНЫМИ ограничениями (не маркетинг фреймворков).
|
||||
- Как это делают CAT/пром-MT тулы и переводчики-практики (сегментация по смысловым блокам, не по строкам).
|
||||
- Академия по кросс-предложенческой когезии, релевантная нарезке: Voita (дейксис/эллипсис/когезия), DelTA / running-summary, document-level MT context windows.
|
||||
**Выход:** реализуемый в СТАТИЧЕСКОМ Go-коде дизайн: (а) стратегия `logical` (сцена/диалог/тема-граница) с **фоллбек-лестницей** и инвариантом «никогда не резать предложение»; (б) какие сигналы границы детектируемы БЕЗ модель-вызовов (дёшево — владелец: «не модель-вызовами размечать чанк»); (в) конкретные фоллбеки при провале детекции. Рассмотри ВСЕ кейсы, не только «1-2-3-4 мелкие главы влезли в чанк» (это простейший).
|
||||
- Учти что при чанковании книги в модели загружаются разные промты-роли, это может быть не только переводчик, а например еще и редактор, который будет подхыватывать оригинал - как тут действовать чанками?
|
||||
- Важная деталь: мы знаем что модели на середине контекста начинают бредить или теряться в чем-то, поэтому стоит речекнуть исследования в этом плане, плюс возможно почитать что уже в репозитории есть по тестам полигона в этом
|
||||
**Выход:** реализуемый в СТАТИЧЕСКОМ Go-коде дизайн: (а) стратегия `logical` (сцена/диалог/тема-граница) с **фоллбек-лестницей** и инвариантом «никогда не резать предложение»; (б) какие сигналы границы детектируемы БЕЗ модель-вызовов (дёшево — владелец: «не модель-вызовами размечать чанк»); (в) конкретные фоллбеки при провале детекции. Рассмотри ВСЕ кейсы, не только «1-2-3-4 мелкие главы влезли в чанк» (это простейший).
|
||||
|
||||
### Задача 2 — Дизайн меж-чанковой когезии
|
||||
Спроектируй механизм, закрывающий претензию-2 «понимание связей» при чанк-изоляции + zh zero-anaphora:
|
||||
640
docs/research/19-chunking-cohesion-sources.md
Normal file
640
docs/research/19-chunking-cohesion-sources.md
Normal file
|
|
@ -0,0 +1,640 @@
|
|||
# research/19 — приложение: источники и вердикты адверсариальной верификации
|
||||
|
||||
> Сгенерировано сессией-ресёрчером 2026-07-16. Веб-фактура: 65-агентный workflow (8 тем + верификация + critic + добор).
|
||||
> Формат: [LB]=несущий клейм, [M]=есть измерение. VERDICT — вердикт независимого верификатора по первоисточнику
|
||||
> (CONFIRMED / OVERSTATED с коррекцией / UNVERIFIABLE); клеймы без VERDICT — не попали под кап верификации (5/тему).
|
||||
|
||||
## t1-chunk-eng — Engineering best practices for splitting long documents for LLM processing — measured limitations of
|
||||
|
||||
- **[LB/M]** In a controlled comparison of fixed-size vs breakpoint-based and clustering-based semantic chunking across document retrieval (10 datasets), evidence retrieval (5 RAGBench datasets), and answer generation, semantic chunking showed no consistent advantage: fixed-size won on most natural (non-stitched) datasets, semantic won only on artificially stitched high-topic-diversity corpora, and answer-generation differences were ~±0.01 BERTScore.
|
||||
- Источник (paper): https://arxiv.org/abs/2410.13070 — 'Is Semantic Chunking Worth the Computational Cost?' (arXiv 2410.13070, 2024)
|
||||
- Каветы: Entirely retrieval-pipeline-oriented (F1@5, retrieval-based QA with gpt-4o-mini on top-5 chunks); it does not test sequential full-coverage processing. The stitched-dataset wins for semantic chunking (e.g. Miracl F1@5 81.89% vs 69.45%) are on synthetic multi-topic concatenations unlike a single novel's chapter.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ /M]** The same study found embedding-model choice dominated chunking-strategy choice: the dunzhang/stella embedder gave a 7.44% average improvement (p=1.59e-5), larger than any gap between chunkers, and retrieval performance correlated only weakly with answer-generation quality.
|
||||
- Источник (paper): https://arxiv.org/html/2410.13070v1 — 'Is Semantic Chunking Worth the Computational Cost?' full text
|
||||
- Каветы: Same single origin as the previous finding — counts as one voice. The weak retrieval→generation coupling is itself a warning against transferring any retrieval-metric result to generation quality.
|
||||
- **[ /M]** Chroma's technical report (472 synthetic queries, 5 corpora, 328K tokens, token-level recall/precision/IoU): chunking strategy choice moves recall by up to ~9 points; a well-parametrized RecursiveCharacterTextSplitter (200 tokens, no overlap) reached 88.1% recall vs 91.9% for an LLM-based semantic chunker; reducing chunk overlap improved IoU while keeping comparable recall; the popular default of 800 tokens with 400-token overlap scored below average on recall and worst on all efficiency metrics.
|
||||
- Источник (practitioner): https://www.trychroma.com/research/evaluating-chunking — 'Evaluating Chunking Strategies for Retrieval', Chroma Technical Report, July 2024
|
||||
- Каветы: Vendor technical report (embedding-DB company), retrieval metrics only; recall/IoU have no analogue in full-coverage translation. Its overlap finding (overlap ≈ redundancy) is about embedding-index redundancy, not about generation context. Many 2025-26 chunking blog posts recycle these exact numbers — they are one voice, not independent confirmation.
|
||||
- **[LB/M]** LumberChunker, an LLM-driven segmenter built specifically for narrative books (iteratively prompting an LLM to find where content shifts), beat the strongest baseline by 7.37% DCG@20 on GutenQA (3,000 needle-in-haystack QA pairs over 100 Project Gutenberg narrative books).
|
||||
- Источник (paper): https://arxiv.org/abs/2406.17526 — 'LumberChunker: Long-Form Narrative Document Segmentation' (2024)
|
||||
- Каветы: This is the strongest published counter-evidence to 'deterministic chunking suffices for narrative' — but the gain is (a) retrieval-only (dense retrieval DCG, no generation task), (b) modest, and (c) bought with per-document LLM calls, which the design constraint (deterministic Go code, no model calls) forbids. No evidence it would improve sequential translation.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** For literary translation specifically, translating whole paragraphs beats sentence-by-sentence translation: across 18 language pairs (incl. Japanese, Polish), with ~350 hours of professional-translator span-level error annotation, GPT-3.5 paragraph-level translation produced fewer mistranslations, grammar errors, and stylistic inconsistencies — but occasionally introduced content omissions absent in sentence-level mode.
|
||||
- Источник (paper): https://aclanthology.org/2023.wmt-1.41/ — Karpinska & Iyyer, 'Large Language Models Effectively Leverage Document-level Context for Literary Translation, but Critical Errors Persist', WMT 2023
|
||||
- Каветы: GPT-3.5-era models; magnitude of reductions is in the paper's tables, not the abstract. The omission side-effect of longer translation units is directly relevant: larger chunks trade boundary errors for silent drops, which motivates an omission/coverage guard rather than maximal chunk size.
|
||||
- **VERDICT: OVERSTATED** — коррекция: For literary translation, translating whole paragraphs beats sentence-by-sentence translation: across 18 linguistically-diverse language pairs (incl. Japanese, Polish, English), in a human evaluation taking ~350 hours of annotation and analysis by hired bilingual translators providing span-level error annotations, GPT-3.5 (text-davinci-003) paragraph-level translation produced fewer mistranslations, grammar errors, and stylistic inconsistencies — but content omissions, while present in all systems, were more prominent in paragraph-level mode than in sentence-level mode.
|
||||
- **[LB/M]** A human study on En→Ru subtitles found 8.5% of translation pairs judged good in isolation (140 of 1,649) were wrong when read in context; of the identified context-dependent inconsistencies, deixis accounted for 37%, ellipsis 29%, and lexical cohesion 14% (~80% together; anaphora 6%, ambiguity 9%).
|
||||
- Источник (paper): https://aclanthology.org/P19-1116/ (arXiv:1905.05979) — Voita, Sennrich, Titov, 'When a Good Translation is Wrong in Context', ACL 2019
|
||||
- Каветы: 2019, pre-LLM sentence-level NMT, En→Ru OpenSubtitles — absolute rates for modern LLMs given in-prompt context are surely lower and unmeasured; but the taxonomy of WHAT breaks when a translation unit is cut off from prior context (pronouns/deixis, elided material, lexical/term cohesion) is the best measured inventory of chunk-boundary failure modes for translation, and Ru is the target language of this pipeline.
|
||||
- **VERDICT: OVERSTATED** — коррекция: A human study on 2,000 consecutive-sentence pairs of En→Ru subtitle translations found that in 7% of cases (140 of 2,000; equivalently ~7.8% of the 1,789 pairs whose sentences were individually good) the translations were good in isolation but bad in the context of each other; among these context-dependent inconsistencies, deixis accounted for 37%, ellipsis 29%, and lexical cohesion 14% (~80% together; ambiguity 9%, anaphora 6%, other 5%).
|
||||
- **[LB/M]** Translation quality degrades measurably with input length even well inside the context window: NLLB loses ~10 BLEU / ~0.2 COMET translating 256-token blocks vs isolated sentences; repetition-loop rate rises from 4% at 256 tokens to 81% at 2,048 tokens; TowerBase-7B (decoder, RoPE) degrades sharply past its 1,024-token training length; and within a document, sentences occurring later are translated systematically worse (position bias), with outputs also becoming too short.
|
||||
- Источник (paper): https://arxiv.org/html/2412.17592v2 — 'Investigating Length Issues in Document-level Machine Translation' (2024/25)
|
||||
- Каветы: Measured on NLLB and TowerBase-7B, i.e. small/specialized MT models, not frontier chat LLMs — the exact thresholds do not transfer, but the qualitative pattern (bigger chunk != free; repetition, truncation, and late-position degradation grow with chunk length) is corroborated by practitioner experience with long generations.
|
||||
- **VERDICT: OVERSTATED** — коррекция: Translation quality degrades measurably with input length even well inside the context window (EN->FR, TED pseudo-documents): NLLB-600M loses ~10 ds-BLEU / ~0.2 COMET translating 256-token blocks vs isolated sentences; the share of NLLB outputs containing long (>=10-gram) repetitions rises from 4% at 256 tokens to 81% at 2,048 tokens; TowerBase-7B (decoder, RoPE) shows a sharp BLEU decline past 1,024 tokens — well below its 4,096-token Llama2 context — with COMET already dropping at 256 tokens, which the authors attribute to continued pretraining mostly on isolated sentences; within a document, later sentences are translated systematically worse (position bias), and NLLB's outputs also become too short.
|
||||
- **[ /M]** In the closest published analogue to sequential full-coverage processing — book-length summarization by chunked traversal — 1,193 human annotations of GPT-4 summaries of 100 books yielded eight recurring coherence error types; incremental (running-state) processing benefited from larger chunks (Claude 2 at 88K-token chunks: 90.9 incremental vs 90.3 hierarchical BooookScore), while hierarchical merging did not.
|
||||
- Источник (paper): https://arxiv.org/abs/2310.00785 — Chang et al., 'BooookScore: A systematic exploration of book-length summarization in the era of LLMs', ICLR 2024
|
||||
- Каветы: Summarization compresses (errors of omission tolerated); translation must preserve everything, so 'bigger chunks help incremental workflows' collides with the doc-MT length-degradation evidence above. Treat as evidence that sequential chunked pipelines produce measurable cross-chunk coherence errors, not as a chunk-size prescription.
|
||||
- **[LB/M]** DelTA (ICLR 2025) shows that explicit deterministic state — a proper-noun record reusing each noun's first translation, plus bilingual summary and short/long-term memory — raises document-translation consistency scores by up to 4.58 points and COMET by up to 3.16 over strong long-context baselines across four LLMs and two doc-translation datasets, and keeps proper-noun translations consistent even across large distances in novels.
|
||||
- Источник (paper): https://arxiv.org/abs/2410.08143 — Wang et al., 'DelTA: An Online Document-Level Translation Agent Based on Multi-Level Memory', ICLR 2025
|
||||
- Каветы: DelTA translates sentence-by-sentence with memory (its own quality ceiling per Karpinska's paragraph findings); its memory components are LLM-maintained, not free. The transferable result: terminology cohesion across chunks is best solved by an explicit glossary/memory carried into every chunk's prompt, not by chunk overlap or bigger chunks.
|
||||
- **[ /M]** Industry practitioner baseline for RAG chunking is ~400-512 tokens with 10-20% overlap (Pinecone's oft-cited starting point: 512 tokens, 50-100 token overlap), with overlap justified as insurance against sentences split across chunk boundaries; recent systematic analyses find no universal optimum — optimal chunk size varies by dataset and document length (tested on NarrativeQA, NQ, NewsQA, SQuAD etc.), and wrong choices cost up to ~9% recall.
|
||||
- Источник (blog): https://arxiv.org/pdf/2505.21700 — 'Rethinking Chunk Size For Long-Document Retrieval: A Multi-Dataset Analysis'; practitioner defaults per https://www.firecrawl.dev/blog/best-chunking-strategies-rag and https://www.digitalapplied.com/blog/rag-chunking-strategies-2026-retrieval-quality-playbook
|
||||
- Каветы: The 512/10-20% numbers are practitioner folklore (vendor blogs, one Pinecone origin), not derived for generation; the measured part (no universal optimum, dataset-dependent) is the arXiv paper. All of it is retrieval-recall-oriented; the overlap rationale (rescuing split sentences) is moot for a chunker that is forbidden to split sentences in the first place.
|
||||
- **[ ]** Sentence-window and parent-document patterns are officially documented as retrieval decoupling mechanisms: index/match on a small unit (single sentence; small child chunk) but hand the LLM a larger surrounding context at generation time (LlamaIndex SentenceWindowNodeParser stores a window of surrounding sentences in metadata and swaps it in before the LLM sees the node; parent-document retrieval returns the parent of a matched child).
|
||||
- Источник (official-doc): https://developers.llamaindex.ai/python/framework-api-reference/node_parsers/sentence_window/ and https://developers.llamaindex.ai/python/framework/module_guides/loading/node_parsers/modules/ — LlamaIndex official documentation
|
||||
- Каветы: Pattern definitions, no benchmark numbers. In a no-retrieval sequential pipeline the pattern degenerates to its useful core: the unit the model must produce output for need not equal the context it is shown — i.e. asymmetric read-only context around each translation chunk.
|
||||
- **[ /M]** Follow-up empirical studies since 2410.13070 continue to find the semantic-vs-fixed trade-off unresolved and cost-dominated: a 2026 evaluation on academic texts (RAGAs framework) and a cost-focused study both report semantic chunking's coherence gains are 'not always proportional to the increased computational cost', with cluster-based semantic chunking reported roughly an order of magnitude slower to index than token-based splitting.
|
||||
- Источник (paper): https://arxiv.org/html/2606.00881v1 — 'Chunking Methods on Retrieval-Augmented Generation – Effectiveness Evaluation Against Computational Cost and Limitations'; https://arxiv.org/html/2607.01852v1 — 'Evaluating Chunking Strategies for RAG on Academic Texts'
|
||||
- Каветы: Skimmed via search snippets only, not deep-read; the widely repeated '~14x slower' figure could not be traced to a primary table and should be treated as unverified direction-of-effect, not a number. Both are again retrieval-pipeline studies.
|
||||
|
||||
## t2-segmentation — Deterministic (non-LLM) text segmentation for narrative fiction: classic algorithms (TextTiling, C99
|
||||
|
||||
- **[ ]** TextTiling (Hearst 1997) segments text into multi-paragraph subtopic units by sliding two adjacent bag-of-words blocks over the text, computing cosine lexical similarity, and placing boundaries at valleys (local minima) of the cohesion score; it is fully deterministic and was validated against human subtopic judgments on 12 expository texts.
|
||||
- Источник (paper): https://dl.acm.org/doi/10.5555/972684.972687 — Hearst, "TextTiling: segmenting text into multi-paragraph subtopic passages", Computational Linguistics 23(1), 1997; also https://www.semanticscholar.org/paper/cb91a9ef1723440bd35a3e5965a2e180ad1ab36f
|
||||
- Каветы: Validated on expository text (science magazine articles), not narrative fiction; 'corresponds well' is a qualitative claim on 12 texts, no modern-style benchmark.
|
||||
- **[LB/M]** C99 (Choi 2000) replaces TextTiling's raw similarity with a local rank matrix plus divisive clustering, and on Choi's synthetic benchmark (700 samples, each a concatenation of 10 random Brown-corpus segments) achieved 13% error vs 46% for TextTiling, 22% for DotPlot, 36% for Segmenter (3-11 sentence variant).
|
||||
- Источник (paper): https://arxiv.org/pdf/cs/0003083 — Choi, "Advances in domain independent linear text segmentation", NAACL 2000 (also http://www.cs.columbia.edu/~julia/papers/choi00.pdf)
|
||||
- Каветы: CRITICAL caveat: the benchmark concatenates unrelated documents, so 'boundaries' are trivially strong topic shifts; numbers do NOT transfer to within-document or narrative boundaries. TextTiling's 44-48% error even here shows raw TextTiling is weak out of the box.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ ]** BayesSeg (Eisenstein & Barzilay, EMNLP 2008) models each segment's words as draws from a segment-specific multinomial language model plus probabilistic cue-phrase models, maximizing observation likelihood to get a lexically-cohesive segmentation; a 2024 survey judges its results "still competitive" among non-neural methods.
|
||||
- Источник (paper): https://aclanthology.org/D08-1035/ — Eisenstein & Barzilay, "Bayesian Unsupervised Topic Segmentation"; survey characterization from https://arxiv.org/abs/2411.16613 — "Recent Trends in Linear Text Segmentation: a Survey" (EMNLP Findings 2024)
|
||||
- Каветы: Evaluated on expository/spoken corpora (textbooks, meetings), not fiction. I could not extract the original Pk numbers from the PDF; the 'still competitive' judgment is the survey authors' opinion.
|
||||
- **[LB/M]** GraphSeg (Glavaš et al., *SEM 2016), an unsupervised word-embedding graph method, scores excellently on the synthetic Choi dataset (Pk 5.6-7.2) but on natural Wikipedia documents (WIKI-50) gets Pk 63.56 — WORSE than a random baseline (52.65), i.e., embedding-similarity methods tuned on synthetic benchmarks can fail completely on real single-document segmentation.
|
||||
- Источник (paper): https://ar5iv.labs.arxiv.org/html/1803.09337 — Koshorek et al., "Text Segmentation as a Supervised Learning Task", NAACL 2018 (GraphSeg original: https://aclanthology.org/S16-2016/)
|
||||
- Каветы: Numbers as reported by Koshorek et al. (a competing paper), not by GraphSeg's authors; Pk is lower-is-better. Strongly warns against selecting a chunking algorithm based on Choi-dataset scores.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** A supervised neural segmenter trained on 727,746 Wikipedia documents (WIKI-727K) achieves Pk 22.13 on the WIKI-727K test set and 18.24 on WIKI-50, while trained human annotators achieve Pk 14.97 on WIKI-50 — i.e., even massive supervision leaves ~20% window-error, and the human ceiling itself is far from 0.
|
||||
- Источник (paper): https://aclanthology.org/N18-2075/ and https://ar5iv.labs.arxiv.org/html/1803.09337 — Koshorek et al., "Text Segmentation as a Supervised Learning Task", NAACL 2018
|
||||
- Каветы: Wikipedia section boundaries, not narrative scenes; segmentation granularity is genuinely ambiguous even for humans, which bounds any algorithm's achievable 'accuracy'.
|
||||
- **VERDICT: OVERSTATED** — коррекция: A supervised neural segmenter trained on the 80% training split of the 727,746-document WIKI-727K corpus achieves Pk 22.13 on the WIKI-727K test set and 18.24 on WIKI-50, while human annotators (of unspecified training; the authors note they annotated only a few documents and 'lack familiarity with the right level of granularity', so 14.97 is a lower bound on the human gap, not a certified ceiling) achieve Pk 14.97 on WIKI-50 — massive supervision still leaves ~18-22% window-error, and even this human baseline is far from 0.
|
||||
- **[LB/M]** The first dedicated narrative scene segmentation corpus (Zehe et al., EACL 2021) defines a scene as a segment where story time ≈ discourse time and action, location, and character constellation stay constant; on 550k tokens of German dime novels (inter-annotator agreement gamma = 0.7) a BERT baseline reached only F1 24%.
|
||||
- Источник (paper): https://aclanthology.org/2021.eacl-main.276/ — Zehe et al., "Detecting Scenes in Fiction: A new Segmentation Task", EACL 2021
|
||||
- Каветы: German-language dime novels only; gamma=0.7 means humans themselves disagree substantially on scene boundaries. Same research group as STSS 2021 and the NAACL 2025 follow-up — treat the three as ONE research lineage, not independent confirmations.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** In the STSS 2021 shared task (KONVENS), 5 teams trained on 20 annotated German dime novels; the best models reached F1 = 37% on in-domain dime novels (Track 1) and F1 = 26% on out-of-domain 19th-century highbrow literature (Track 2) — the organizers conclude scene segmentation is 'very challenging' but 'feasible in principle'.
|
||||
- Источник (paper): https://ceur-ws.org/Vol-3001/paper1.pdf and https://nilsreiter.de/publications/Zehe2021ab — Zehe et al., "Shared Task on Scene Segmentation @ KONVENS 2021"
|
||||
- Каветы: This is THE realistic accuracy anchor for narrative scene boundaries: ~1/3 F1 in-domain, ~1/4 out-of-domain. Same one-voice caveat (Würzburg/Zehe group). Exact metric tolerance definition not extracted from the PDF.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ ]** STSS 2021 participating systems used exactly the signal families relevant to a deterministic chunker: embedding-delta signals between adjacent windows, coreference chains of entities, temporal/spatial/entity feature vectors, twin-BERT embeddings + gradient-boosted trees, and sequential sentence classification — none exceeded 37% F1.
|
||||
- Источник (paper): https://ceur-ws.org/Vol-3001/ — CEUR-WS Vol-3001, STSS 2021 proceedings (papers by Schneider et al.; Hatzel & Biemann; Barth & Dönicke; Gombert; Kurfali & Wirén)
|
||||
- Каветы: Signal inventory inferred from paper titles and the volume index; per-team feature ablations not extracted.
|
||||
- **[ ]** The 2025 follow-up ("Assessing the State of the Art in Scene Segmentation", NAACL 2025) compared BERT-based and Llama-based models: Llama models are more robust across text types but slightly WORSE overall than BERT-based ones; a corrected training procedure gave a significant improvement, yet the task 'is very challenging for automatic methods, since it requires a high-level understanding of the text'.
|
||||
- Источник (paper): https://aclanthology.org/2025.naacl-long.500/ — "Assessing the State of the Art in Scene Segmentation", NAACL 2025
|
||||
- Каветы: Abstract-level claims only — exact F1 numbers could not be extracted (PDF did not parse). Same Zehe research lineage. Implication: even LLM-class models have not 'solved' scene segmentation as of 2025.
|
||||
- **[LB/M]** For Chinese, character/syllable n-gram variants of TextTiling not only work without word segmentation but BEAT word-based TextTiling: on the TDT2 Mandarin broadcast-news corpus, character-bigram TextTiling gave +8.84% relative F-measure and syllable bigrams +7.11% over word-based cohesion, and subword units are robust to word-segmentation ambiguity and OOV items.
|
||||
- Источник (paper): https://link.springer.com/chapter/10.1007/978-3-540-68636-1_33 — "Multi-Scale TextTiling for Automatic Story Segmentation in Chinese Broadcast News" (AIRS 2008); related: https://ieeexplore.ieee.org/document/4730355 (Subword LSA for TextTiling-based story segmentation) and https://link.springer.com/chapter/10.1007/978-3-540-89796-5_26 (subword lexical chaining)
|
||||
- Каветы: Task is story-boundary detection in broadcast-news transcripts (coarse, topic-level boundaries), NOT fiction scenes; the whole subword-TextTiling cluster comes from one group (Xie Lei et al., NWPU) — one voice, multiple papers. Still, it directly licenses a Go character-bigram cohesion scorer with no Chinese tokenizer.
|
||||
- **[LB]** The 2024 EMNLP-Findings survey of linear text segmentation states: unsupervised classics are generally outperformed by supervised transformer systems but remain relevant for low-resource settings; supervised models 'tend to overfit to specific cue phrases and domain-specific features'; and the standard metrics Pk and WindowDiff 'over-penalize near misses' and behave inconsistently in edge cases (Boundary Similarity recommended); literary text and non-English data are explicitly under-covered.
|
||||
- Источник (paper): https://arxiv.org/abs/2411.16613 — Bertsch et al.(?), "Recent Trends in Linear Text Segmentation: a Survey", Findings of EMNLP 2024 (https://aclanthology.org/2024.findings-emnlp.174.pdf)
|
||||
- Каветы: Survey = secondary source aggregating others' results; its exclusion of the literary domain means its SOTA statements do not directly cover fiction.
|
||||
- **[ ]** In English-language fiction manuscript convention, scene breaks are explicitly typographically marked: a blank-line break set off with '#' (or asterisks), with major vs minor breaks distinguishable — i.e., in edited fiction the scene boundary is usually a surface-visible token, not something to infer.
|
||||
- Источник (practitioner): https://www.shunn.net/format/scene_breaks/ — William Shunn, "Proper Manuscript Format: Scene Breaks"
|
||||
- Каветы: Publishing/manuscript convention, not a study; webnovel raw text (especially scraped/OCR zh sources) may lose or never contain these markers.
|
||||
- **[LB]** Japanese web novels (Syosetu/Kakuyomu culture) use blank lines pervasively as readability whitespace — guides recommend a blank line roughly every 5-10 lines and around dialogue — while ACTUAL scene changes are marked by dedicated separator symbols (*, ◇, ◆, ■, ○, often repeated 1-3 times), a convention described as mainstream and low-cost for readers; vertical-phone reading makes dense text a psychological barrier.
|
||||
- Источник (practitioner): https://ncode.syosetu.com/n9885er/6/ — "web小説の書き方、ルール文書規則 — 6. 改行、空白行、セパレーター" (Syosetu writing-rules guide); https://novelmore.jp/blog/write/novel-scene-transition/ — "場面転換を使いこなす!" (Novelmore); https://www.hibibenkyo.com/novel-web-blank/
|
||||
- Каветы: Writing-guide/community sources (practitioner, not academic); quotes obtained via search snippets of the guides. Key design consequence: in ja webnovels a blank line is NOT a scene-break signal, but an ornament/asterism line IS.
|
||||
- **[LB]** Chinese webnovel chapters are short and mobile-optimized: ~2,000-5,000 characters per chapter (platform guide), ~3,000 characters per posted chapter with a chapter readable in ~10 minutes (Guangming Daily cultural-desk article), released 1-2+ chapters/day; total works run to millions of characters via '化整为零' (breaking the whole into small pieces).
|
||||
- Источник (practitioner): https://read.teanovel.com/blog/chinese-web-novel-beginners-guide — TeaNovel, "Chinese Web Novels: A Complete Beginner's Guide"; https://news.gmw.cn/2023-07/16/content_36698429.htm — 光明网/Guangming, "网络小说和短视频的「长」与「短」"
|
||||
- Каветы: TeaNovel is a reader-platform blog; Guangming is a state-media culture article — consistent but not a corpus study. Webnovel.com Q&A pages give 2,000-8,000 as the platform requirement range, consistent with this.
|
||||
- **[LB]** Chinese webnovel prose convention has converged on very short paragraphs — one or two sentences per paragraph (一句一段) — explicitly attributed by Chinese writing guides to phone-screen reading fatigue; top authors are described as near-universally adopting one-sentence-per-paragraph, and paragraph rhythm is treated as a pacing device.
|
||||
- Источник (blog): https://zhuanlan.zhihu.com/p/689906206 — 知乎, "新手小白写网络小说,从零开始的网文写作攻略"; https://jingyan.baidu.com/article/3ea51489d03bc852e71bba59.html — 百度经验, "自己写的原创网络小说怎么排版"; https://www.wenxiaobai.com/api/expends/detail?article=37f67397-cd83-452e-9e70-2485f5220187 — "小说的分段技巧"
|
||||
- Каветы: Community/how-to sources aggregated via search snippets — no academic corpus statistics found on zh-webnovel paragraph length or on 分割线 scene-divider frequency. Design consequence: zh paragraph boundary ≈ sentence boundary (dense, weakly informative); do not treat each paragraph break as a cohesion event.
|
||||
- **[ /M]** Film/video scene boundary detection is likewise unsolved-but-improving on its own benchmark: MovieNet-SSeg annotates scene boundaries in 318 movies (train/val/test 190/64/64), evaluated by Average Precision; self-supervised ShotCoL raised SOTA AP by 13% relative (2021) and later multimodal methods (Scene-VLM, 2025) added +6 AP more — signals are shot-level visual/audio, not transferable to prose.
|
||||
- Источник (paper): https://arxiv.org/pdf/2007.10937 — Huang et al., "MovieNet: A Holistic Dataset for Movie Understanding" (ECCV 2020); https://www.researchgate.net/publication/355881826 — ShotCoL (CVPR 2021); https://arxiv.org/html/2512.21778v2 — Scene-VLM
|
||||
- Каветы: Different modality (video shots pre-segment the stream — prose has no shot analog); included only as an analogy that 'scene' is a hard, granularity-ambiguous unit in every medium.
|
||||
|
||||
## t3-docmt — Document-level MT and cross-sentence cohesion: measured shares of context-dependent errors, how much
|
||||
|
||||
- **[LB/M]** In Voita et al. 2019 (en->ru OpenSubtitles), human annotation of 2000 consecutive-sentence pairs found 7% of pairs where each translation was good in isolation but wrong/inconsistent in context (a further 11% had at least one sentence-level error). Among those context-dependent inconsistencies: deixis 37%, ellipsis 29%, lexical cohesion 14% (the three together = 80%), ambiguity 9%, anaphora 6%, other 5%.
|
||||
- Источник (paper): https://aclanthology.org/P19-1116/ (When a Good Translation is Wrong in Context, ACL 2019) + author's explainer https://lena-voita.github.io/posts/acl19_context.html
|
||||
- Каветы: Domain is en->ru movie subtitles (short, dialogue-heavy sentences); shares for long-form literary prose may differ. The 7% is a share of sentence PAIRS, not of all errors.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Voita et al.'s contrastive test sets place the disambiguating context within at most 3 previous sentences by construction: each instance = 3 context sentences + current sentence; deixis (3000 ex.) has 1000 examples each at antecedent distance 1/2/3 sentences back; lexical cohesion (2000 ex.) is distributed 855/630/515 across distances 1-3; CADec consumes up to 3 previous sentences on both source and target sides.
|
||||
- Источник (paper): https://github.com/lena-voita/good-translation-wrong-in-context (official data/code repo for ACL 2019 + EMNLP 2019 papers)
|
||||
- Каветы: The <=3-sentence distance is a test-set DESIGN choice, not a measurement of the natural distance distribution of cohesion dependencies; long-range dependencies (character names, honorifics, running metaphors in novels) are outside its scope. Same research group (Voita/Sennrich/Titov) as the previous finding — one voice.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ /M]** CADec (context-aware two-pass decoder refining a context-agnostic translation with 3 previous sentences) raised contrastive accuracy over the baseline: deixis 50.0%->81.6%, ellipsis-inflection 53.0%->72.2%, ellipsis-VP 28.4%->80.0%, lexical cohesion 45.9%->58.1%, with no BLEU loss.
|
||||
- Источник (paper): https://aclanthology.org/P19-1116/ (When a Good Translation is Wrong in Context, ACL 2019; numbers via ar5iv https://ar5iv.labs.arxiv.org/html/1905.05979)
|
||||
- Каветы: 2019-era Transformer NMT on subtitles; absolute numbers do not transfer to LLM pipelines, but the two-pass 'draft then context-aware refine' architecture pattern does.
|
||||
- **[LB/M]** DocRepair (Voita et al., EMNLP 2019): a MONOLINGUAL target-side repair model operating on sliding groups of 4 consecutive sentences (no source access) fixed most cohesion errors — deixis 91.8%, lexical cohesion 80.6%, ellipsis-inflection 86.4%, ellipsis-VP 75.2% (vs baseline 50.0/45.9/53.0/28.4) — with +0.69 BLEU (33.91->34.60); where annotators had a preference, 73% preferred DocRepair output.
|
||||
- Источник (paper): https://aclanthology.org/D19-1081/ (Context-Aware Monolingual Repair for Neural Machine Translation, EMNLP 2019; numbers via ar5iv https://ar5iv.labs.arxiv.org/html/1909.01383)
|
||||
- Каветы: Same authors as CADec/ACL-2019 — the whole Voita line is ONE voice. Trained via round-trip translation on monolingual data; en->ru subtitles. VP-ellipsis is the one phenomenon where source-less repair underperformed CADec (75.2 vs 80.0) — some repairs genuinely need the source.
|
||||
- **VERDICT: OVERSTATED** — коррекция: DocRepair (Voita et al., EMNLP-IJCNLP 2019): a MONOLINGUAL target-side repair model operating on groups of 4 consecutive sentences (no source access; the paper does not specify sliding/overlapping windows) scored deixis 91.8%, lexical cohesion 80.6%, ellipsis-inflection 86.4%, ellipsis-VP 75.2% on consistency test sets (vs baseline 50.0/45.9/53.0/28.4), with +0.69 BLEU (33.91->34.60) on 4-sentence fragments; among human-eval cases where annotators had a preference, 73% preferred DocRepair output.
|
||||
- **[LB/M]** Fernandes et al. 2021 (CXMI metric, en->de/en->fr IWSLT): the largest jump in measured context usage comes from adding the FIRST context sentence; additional sentences give diminishing returns, and target-side context is used more than source-side context. Context-aware word dropout increased usage and gave +0.5-1.4 BLEU plus contrastive-set gains.
|
||||
- Источник (paper): https://aclanthology.org/2021.acl-long.505/ (Measuring and Increasing Context Usage in Context-Aware Machine Translation, ACL 2021; arXiv https://arxiv.org/abs/2105.03482)
|
||||
- Каветы: Small NMT models on TED talks; 'models fail to use more context' is a property of THOSE models, not proof extra context is useless for LLMs. Fernandes/Neubig group overlaps with the MuDA paper below — related voice.
|
||||
- **VERDICT: OVERSTATED** — коррекция: Fernandes et al. 2021 (CXMI, en->de/en->fr IWSLT2017): the largest jump in measured context usage comes from adding the first context sentence, with diminishing (sometimes negative, source-side) returns for more sentences, and target-side context is slightly more used than source-side. Context-aware word dropout increased measured context usage and gave roughly +0.5 to +0.9 BLEU for non-pretrained contextual models (near-zero or slightly negative BLEU change with pretraining), plus clear contrastive-set gains in pronoun resolution and lexical cohesion.
|
||||
- **[ /M]** Kim, Tran & Ney 2019: in a manual analysis of a document-level NMT system's improvements, only ~5% of improved cases were attributable to genuine context use (pronoun resolution or topic-appropriate lexical choice); the rest looked like regularization effects, and feeding LONGER context degraded quality unless the context was filtered to content words.
|
||||
- Источник (paper): https://aclanthology.org/D19-6503/ (When and Why is Document-level Context Useful in Neural Machine Translation?, DiscoMT 2019); numbers via summary https://jlibovicky.github.io/2019/10/31/MT-Weekly-Document-Context.html
|
||||
- Каветы: The ~5% figure was verified against a blog summary, not the primary PDF (ar5iv conversion failed); primary abstract confirms the qualitative conclusions ('most improvements not interpretable as utilizing context', 'very long context not helpful'). 2019 RNN/Transformer NMT — LLM-era results (Karpinska below) partially supersede.
|
||||
- **[LB/M]** Cataphora/lookahead: Wong, Maruf & Haffari 2020 measured that ~16% of pronouns in the subtitles domain are cataphoric, ~37% of those resolvable within the single FOLLOWING sentence; an NMT model given one NEXT sentence as context beat the context-agnostic baseline (e.g. en->de BLEU 31.87->32.53, APT 60.8->61.4) and performed comparably to — sometimes better than — the same model given one PREVIOUS sentence, with significant gains on a targeted cataphora suite.
|
||||
- Источник (paper): https://aclanthology.org/2020.acl-main.530/ (Contextual Neural Machine Translation Improves Translation of Cataphoric Pronouns, ACL 2020; arXiv https://arxiv.org/abs/2004.09894)
|
||||
- Каветы: en<->de/pt/ru subtitles, not CJK literary prose; gains are modest in absolute BLEU. Still the clearest direct evidence that lookahead (next-sentence) context measurably helps.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Chinese zero pronouns: 26% of pronouns are dropped in the dialogue domain vs 7% in newswire; ZP-specialized translation methods move general BLEU barely (-0.4 to +0.6 avg) while pronoun-targeted APT jumps (+1.1 to +30.1); with oracle gold zero pronouns inserted, BLEU rises +3.4 and APT +63.4 — i.e., a large measured headroom that generic metrics hide. The survey judges current methods 'still far from real-world use'.
|
||||
- Источник (paper): https://arxiv.org/abs/2305.10196 (A Survey on Zero Pronoun Translation, Wang et al. 2023)
|
||||
- Каветы: Survey aggregates numbers largely from the same Tencent/Wang Longyue research line (also behind GuoFeng/WMT literary tasks) — partially one voice. Dialogue-heavy webnovels sit near the 26% end. For Japanese, an LREC 2020 dataset (https://aclanthology.org/2020.lrec-1.447/) shows context-aware NMT shortcomings on ja->en zero pronouns but publishes no headline error rate in the abstract.
|
||||
- **[LB/M]** LLM literary translation: Karpinska & Iyyer 2023 (GPT-3.5, 18 language pairs incl. ja/zh/ru, paragraphs of mean 7.45 sentences) — translating a WHOLE PARAGRAPH at once was preferred by professional translators over sentence-by-sentence in 71.1% of cases (82.8% vs Google Translate); sentence-level output had 29.5% more mistranslations, 65.4% more grammar errors, and over 12x more consistency errors (25 vs 2), yet critical errors persist even in paragraph mode.
|
||||
- Источник (paper): https://aclanthology.org/2023.wmt-1.41/ (Large language models effectively leverage document-level context for literary translation, but critical errors persist, WMT 2023; arXiv https://arxiv.org/abs/2304.03245)
|
||||
- Каветы: Paragraph-level (≈7 sentences), not chapter-level: the study does NOT show that even bigger single-call windows keep helping; text-davinci-003-era model.
|
||||
- **[ /M]** Par3 (Thai et al., EMNLP 2022; paragraph-aligned world literature): expert literary translators preferred human reference translations over Google Translate output 84% of the time; a GPT-3-based automatic post-editor's output was preferred over the raw MT 69% of the time — i.e., a post-editing/repair stage recovers a large share of literary quality deficit.
|
||||
- Источник (paper): https://aclanthology.org/2022.emnlp-main.672/ (Exploring Document-Level Literary Machine Translation with Parallel Paragraphs from World Literature; arXiv https://arxiv.org/abs/2210.14250)
|
||||
- Каветы: Into-English only; pre-GPT-4 systems; preference rate, not error taxonomy.
|
||||
- **[LB/M]** WMT 2023 Discourse-Level Literary Translation (GuoFeng webnovel corpus, zh->en: 1.9M sentences from 179 webnovels; test documents ~20 consecutive chapters, chapters averaging ~832-1.6K words): human MQM ranking and d-BLEU ranking DIVERGED — GPT-4 was 1st by human MQM (54.81) but only 3rd by d-BLEU (43.7), while the highest-d-BLEU system (52.2) was 2nd by human score; organizers conclude human evaluation is essential for literary discourse quality.
|
||||
- Источник (paper): https://aclanthology.org/2023.wmt-1.3/ (Findings of the WMT 2023 Shared Task on Discourse-Level Literary Translation; arXiv https://arxiv.org/abs/2311.03127); corpus: https://github.com/longyuewangdcu/GuoFeng-Webnovel
|
||||
- Каветы: zh->en only in 2023; MQM by 4 bilingual annotators. WMT 2024 edition (https://aclanthology.org/2024.wmt-1.58/, adds zh->de and zh->ru) again reports 'a significant gap between conclusions drawn from human and automatic evaluations' and scores discourse-aware quality via consistency/word choice/anaphora.
|
||||
- **[ /M]** Sun et al. 2022: naive single-run whole-document Doc2Doc concatenation translation 'yields disappointing translation and even fails' on some corpora (e.g., TED), while multi-resolution training (mixing document windows of several granularities with sentence data) makes Doc2Doc work and gives the best results — evidence that window/chunk granularity, not just total context, is the operative variable.
|
||||
- Источник (paper): https://aclanthology.org/2022.findings-acl.279/ (Rethinking Document-level Neural Machine Translation, Findings of ACL 2022)
|
||||
- Каветы: Encoder-decoder NMT trained from scratch; LLMs with long context behave differently, but 'Investigating Length Issues in Document-level MT' (https://arxiv.org/html/2412.17592) reports quality degradation with very long inputs for LLMs too.
|
||||
- **[ /M]** MuDA (Yin, Fernandes et al., ACL 2023) provides automatic taggers over 14 language pairs to find words whose translation REQUIRES context (pronouns, formality, lexical cohesion, verb form ...), confirming known phenomena and surfacing new ones; it is the standard tool if one wants to quantify, per corpus, how many tokens are context-dependent before choosing chunk boundaries.
|
||||
- Источник (paper): https://aclanthology.org/2023.acl-long.36/ (When Does Translation Require Context? A Data-driven, Multilingual Exploration; arXiv https://arxiv.org/abs/2109.07446)
|
||||
- Каветы: I could not extract the per-language frequency tables (fetch of full text failed), so exact percentages of context-dependent tokens per language remain unverified here; author overlap with Fernandes et al. 2021.
|
||||
- **[ /M]** Post & Junczys-Dowmunt 2023 argue and show that a standard Transformer with sufficient capacity handles document-level translation without bespoke architectures, with training data (document-level back-translation) and evaluation (generative contrastive metrics) being the real bottlenecks.
|
||||
- Источник (paper): https://arxiv.org/abs/2304.12959 (Escaping the sentence-level paradigm in machine translation)
|
||||
- Каветы: arXiv preprint (Microsoft Translator authors); partly a position paper — the architectural claim is measured, the paradigm claim is asserted.
|
||||
|
||||
## t4-agentic-lit-mt — LLM multi-agent/pipeline systems for long literary translation: segmentation units, cross-segment ca
|
||||
|
||||
- **[ ]** DelTA translates strictly sentence-by-sentence in an online (left-to-right) pass, explicitly to guarantee no sentence omissions and keep memory bounded, rather than translating whole chunks/documents per call.
|
||||
- Источник (paper): https://arxiv.org/abs/2410.08143 — DelTA: An Online Document-Level Translation Agent Based on Multi-Level Memory (ICLR 2025)
|
||||
- Каветы: Design description, not a result; sentence-level unit is the cost-maximal extreme of the segmentation spectrum.
|
||||
- **[LB]** DelTA carries four artifacts across segments: (1) Proper Noun Records — (source_noun, first_translation) pairs extracted by an LLM extractor and re-injected whenever the noun reappears, locking the FIRST translation; (2) a Bilingual Summary updated every m=20 sentences (source-side summary covers content/domain/style/tone, target-side covers content), maintained by summarize-then-merge LLM steps; (3) Long-Term Memory — the last l=20 source-target sentence pairs, from which an LLM retriever picks n=2 relevant pairs per query; (4) Short-Term Memory — the last k=3 sentence pairs verbatim.
|
||||
- Источник (paper): https://arxiv.org/html/2410.08143v1 — DelTA paper full text, memory-components section
|
||||
- Каветы: Exact m/l/k/n values extracted via automated read of the arXiv HTML; treat window constants as configuration choices of one paper, not established optima. Retrieval and summary-merge are themselves LLM calls (not deterministic).
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** DelTA's carried memory measurably improves cross-segment consistency and quality vs sentence-isolated and context-window baselines: proper-noun translation consistency (LTCR-1, exact-match agreement with the first translation of each noun) up by up to 4.58 percentage points and COMET up by up to 3.16 points on average, tested on four LLMs (GPT-3.5-Turbo-0125, GPT-4o-mini, Qwen2-7B-Instruct, Qwen2-72B-Instruct) on IWSLT2017 (8 language pairs) and GuoFeng Webnovel Zh→En.
|
||||
- Источник (paper): https://arxiv.org/abs/2410.08143 — DelTA (ICLR 2025)
|
||||
- Каветы: Self-reported by the one origin paper; 2024 models. One extracted table example (IWSLT2017, GPT-3.5, En→Zh: LTCR 77.06%→82.96%) exceeds the abstract's 'up to' figure — per-config numbers vary, so use the abstract-level range. LTCR-1 rewards consistency-with-first-translation, not correctness of that first translation.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** DelTA's stated failure mode is inference cost/latency: auxiliary LLM components (extractor, retriever, summarizers) are 'frequently invoked' per sentence, giving prolonged runtime; its memory advantage over whole-document (Doc2Doc) prompting only materializes past roughly 70 sentences of document length.
|
||||
- Источник (paper): https://arxiv.org/html/2410.08143v1 — DelTA paper, limitations/efficiency discussion
|
||||
- Каветы: The 70-sentence crossover is about GPU memory for locally-served models, not API dollar cost; the runtime complaint is qualitative. Still, per-sentence agent loops multiply call count by sentences x auxiliary components.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ ]** TransAgents segments at CHAPTER level: the execution stage translates chapter-by-chapter over the WMT2023 discourse-level literary translation test set of 12 web novels x 20 consecutive chapters (240 chapters).
|
||||
- Источник (blog): https://gonzoml.substack.com/p/perhaps-beyond-human-translation — detailed review of (Perhaps) Beyond Human Translation (arXiv 2405.11804, TACL 2025)
|
||||
- Каветы: arXiv HTML and TACL page were unfetchable (LaTeXML shell / 403), so chapter-unit and test-set size are taken from a secondary review plus the WMT2023 task description; both trace to the one origin paper.
|
||||
- **[LB]** What TransAgents carries across chapters is a STATIC book-level 'translation guideline' built once in the preparation stage — glossary (Junior Editor over-collects candidate terms chapter-by-chapter, Senior Editor prunes common words, then translates terms in context), chapter summaries merged into a book/plot summary, and tone/style/target-audience decided from ONE randomly selected chapter; the execution stage (Translator → Localization Specialist → Proofreader, each paired with a Judgment critic agent) has no additional running inter-chapter memory, and the paper itself admits cross-chapter consistency 'remains a challenging task'.
|
||||
- Источник (blog): https://www.deeplearning.ai/the-batch/transagents-a-system-that-boosts-literary-translation-with-a-multi-agent-workflow — The Batch (deeplearning.ai) + https://gonzoml.substack.com/p/perhaps-beyond-human-translation
|
||||
- Каветы: Two secondary write-ups of ONE origin paper (arXiv 2405.11804) — one voice, not two. Key negative result: static book-level artifacts alone did not solve chapter-to-chapter consistency.
|
||||
- **VERDICT: OVERSTATED** — коррекция: What TransAgents carries across chapters is a STATIC book-level "translation guideline" built once in the preparation stage — glossary (Junior Editor as Addition agent exhaustively over-collects candidate terms per chapter, Senior Editor as Subtraction agent removes generic ones, then translates the terms in context), chapter summaries compiled into a book summary, and tone/style/target-audience set from one randomly selected chapter; in the execution stage (Translator → Localization Specialist → Proofreader as Action agents, each overseen by a Critique agent (Junior Editor) AND a Judgment agent (Senior Editor)) there is no additional running inter-chapter memory — the TACL version explicitly calls the static guidelines the system's "long-term memory," and the only other cross-chapter mechanism is a final review that checks flow between adjacent chapters. However, the paper does NOT admit that its cross-chapter consistency "remains a challenging task": it frames book-wide coherence/cohesion/consistency as "one of the principal challenges in literary translation" that its guidelines are designed to address, and its case study claims TransAgents maintains global consistency where GPT-4 does not.
|
||||
- **[ /M]** TransAgents' measured evaluation is preference-based and genre-unstable: monolingual human raters preferred it over human reference and GPT-4 only on average (77.8% preference in fantasy-romance vs 39.1% in science fiction); GPT-4-judge bilingual preference over the human Reference 1 ran roughly 66% vs 30%; meanwhile d-BLEU collapsed to 25.0±2.4 vs 47.8 for direct GPT-4 and 47.3 for Google Translate.
|
||||
- Источник (paper): https://www.deeplearning.ai/the-batch/transagents-a-system-that-boosts-literary-translation-with-a-multi-agent-workflow — The Batch; d-BLEU 25.0±2.4 confirmed via search of arXiv 2405.11804
|
||||
- Каветы: All numbers trace to the one TransAgents paper (self-evaluation). The d-BLEU/preference divergence is the paper's own headline tension: judged 'better' while diverging maximally from references.
|
||||
- **[LB]** TransAgents' documented failure mode is content omission and free interpretation: professional translators inspecting outputs noted it 'sometimes losing parts of the original text' (including chapter-title omissions), and The Batch summarizes outputs as 'less-precise interpretations' rather than faithful translations — the multi-agent rewrite loop trades fidelity for fluency.
|
||||
- Источник (blog): https://gonzoml.substack.com/p/perhaps-beyond-human-translation + https://www.deeplearning.ai/the-batch/transagents-a-system-that-boosts-literary-translation-with-a-multi-agent-workflow
|
||||
- Каветы: Qualitative observations from the origin paper's own analysis, relayed by secondary sources; the d-BLEU gap (25.0 vs 47.8) is the quantitative shadow of the same phenomenon.
|
||||
- **VERDICT: OVERSTATED** — коррекция: TransAgents' documented failure mode is content omission and free interpretation: the paper finds both gpt-4-1106-preview and TransAgents "exhibit significant issues with content omission" in chapter segments (chapter titles, by contrast, were rendered consistently by TransAgents — the inconsistency fault there was GPT-4's), and the paper summarizes professional translators' comments as a novel-like expressive style that "sometimes omits parts of the original text"; The Batch describes the outputs as "not word-by-word translations of the inputs but less-precise interpretations" — the pipeline trades fidelity for fluency, though omission was equally present in the vanilla GPT-4 baseline.
|
||||
- **[ /M]** TransAgents' cost was about $2.08 per chapter vs $168.48 per chapter for professional human translation (the ~80x cost-reduction claim), using GPT-4-1106-preview as the backbone.
|
||||
- Источник (blog): https://gonzoml.substack.com/p/perhaps-beyond-human-translation — review of arXiv 2405.11804
|
||||
- Каветы: Secondary source relaying the origin paper (primary PDF unparseable, TACL page 403). 2024 GPT-4-preview pricing; absolute dollars are stale, the ~80x ratio is the durable claim.
|
||||
- **[ ]** TransAgents' human evaluation is methodologically weak: raters were monolingual (never saw the source), judged isolated ~150-word segments drawn only from the first two chapters of each novel, and gave bare preferences with no error typology (unlike MQM) — so the 'preferred over human translation' headline cannot be read as fidelity or book-level cohesion evidence.
|
||||
- Источник (blog): https://gonzoml.substack.com/p/perhaps-beyond-human-translation — (Perhaps) Beyond Human Translation review
|
||||
- Каветы: Criticism from a technical blog review; but the segment construction facts come from the paper's own setup. Marked blog, not peer-reviewed critique.
|
||||
- **[ /M]** Independent evidence that preference-style evaluation overstates LLM literary translation: on LITEVAL-CORPUS (2k+ paragraph-level translations, 4 language pairs, 9 systems incl. GPT-4o/DeepL), professional translators preferred human translations ~94.4% of the time over the best MT/LLM outputs (100% in De-En and De-Zh), and standard MQM was found inadequate for literary translation while evaluator expertise strongly controlled adequacy.
|
||||
- Источник (paper): https://arxiv.org/abs/2410.18697 — How Good Are LLMs for Literary Translation, Really? (LITEVAL-CORPUS, NAACL 2025)
|
||||
- Каветы: Does not include TransAgents/multi-agent systems; paragraph-level (mean 5.7 sentences), authors admit it does not capture document-level nuance. Directly undercuts monolingual-preference claims of human parity.
|
||||
- **[ ]** Andrew Ng's translation-agent chunks purely deterministically — RecursiveCharacterTextSplitter.from_tiktoken_encoder(model_name="gpt-4") with MAX_TOKENS_PER_CHUNK=1000 and an evening function (total_tokens / ceil(total/limit)), zero overlap — and carries NOTHING between chunks: every chunk's prompt embeds the FULL source text with the current chunk wrapped in <TRANSLATE_THIS> tags; no glossary, no summary, no previous translations cross chunks; the translate→reflect→improve loop is entirely within-chunk. No quantitative evaluation is published.
|
||||
- Источник (practitioner): https://github.com/andrewyng/translation-agent — translation-agent repo, src/translation_agent/utils.py
|
||||
- Каветы: Explicitly 'not mature software' (weekend demo). Full-source-per-chunk is O(N²) total prompt tokens over a book and offers no terminology locking — it is a non-solution for book-scale cohesion, but its splitter pattern is a precedent for deterministic Go chunking.
|
||||
- **[LB/M]** At WMT24's discourse-level literary translation task (GuoFeng Webnovel V2; Zh→En test = 12 books, ~239 chapters, ~28.1K words per document), the winning recipes were terminology control plus editor/critic agents on top of chunk translation — NLP2CT-UM: GPT-4o multi-candidate generation with 'a custom terminology table' + xCOMET selection (human General score 3.96/5); SJTU-LoveFiction: chunk-based SFT + a GPT-4o Translation Editor Agent + a 'Term Proofreader Agent' (Discourse 4.13/5) — and NO system reached human translator quality; automatic and human rankings diverged sharply (NTU: sentence BLEU 20.9 but 2.58/5 human).
|
||||
- Источник (paper): https://arxiv.org/html/2412.11732v1 — Findings of the WMT 2024 Shared Task on Discourse-Level Literary Translation (also https://aclanthology.org/2024.wmt-1.58/)
|
||||
- Каветы: Shared-task findings aggregate 10 submissions from 5 teams — multiple independent voices, strongest external validation available that glossary/terminology enforcement is the load-bearing cross-segment artifact for webnovels. Human eval by professional translators (Cohen's kappa 0.86).
|
||||
- **[ /M]** DITING (Oct 2025), the first webnovel-translation-specific benchmark (18K+ expert-annotated Zh-En pairs), finds the discriminating error classes are exactly cross-segment/cultural ones — idiom translation, lexical ambiguity, terminology localization, tense consistency, zero-pronoun resolution, cultural safety; DeepSeek-V3 scored best overall (5.16/6, GPT-4o 5.09), Chinese-trained LLMs beat larger Western models (Qwen3-8B 3.96 > LLaMA3-70B 3.58); its own AgentEval judge correlates with humans at Spearman 0.669 vs ~0.47 for BLEU/COMET/BLEURT; the authors admit the benchmark is sentence-level and 'overlook[s] document-level narrative coherence'.
|
||||
- Источник (paper): https://arxiv.org/abs/2510.09116 — DITING: A Multi-Agent Evaluation Framework for Benchmarking Web Novel Translation
|
||||
- Каветы: Single paper, 2025 models; per-dimension scores are LLM/expert-rubric based, not production reading data. Its Chinese-model advantage is task-specific (Zh webnovel domain) — do not generalize to zh→ru.
|
||||
- **[ ]** 2026 successors are moving from fixed context windows to SELECTED context: G²C-MT frames choosing which previous paragraphs to feed the translator as path discovery over a lightweight discourse graph (nodes = paragraphs; edges = semantic similarity, adjacency, keyword overlap) and reports beating strong baselines on DeepSeek-V3, Gemini-2.5-Flash-lite and Qwen-2.5/3; SAMAS (Feb 2026) is a multi-agent system carrying an extracted style 'spectrum' across a literary work.
|
||||
- Источник (paper): https://arxiv.org/abs/2606.03078 — G²C-MT: Graph-Guided Context Selection for Document-Level Machine Translation; https://arxiv.org/pdf/2602.19840 — SAMAS
|
||||
- Каветы: G²C-MT numeric deltas and SAMAS results were not extractable from fetched excerpts — treat as direction-of-field evidence, not measured gains. Notably G²C-MT's edge features (adjacency, keyword/entity overlap) are computable deterministically without model calls.
|
||||
|
||||
## t5-longcontext — Long-context and long-output LLM degradation evidence for chunk sizing and prompt layout in a book-t
|
||||
|
||||
- **[LB/M]** Lost in the Middle (Liu et al., TACL 2024) measured a U-shaped position effect on multi-document QA and synthetic key-value retrieval ONLY, at modest input sizes (10/20/30 documents, ~3-5K tokens): GPT-3.5-Turbo with 20 documents scored 75.8% with the answer at the beginning vs 53.8% in the middle (a >20-point drop), falling BELOW its 56.1% closed-book baseline. It did not test open-ended generation or translation.
|
||||
- Источник (paper): https://arxiv.org/abs/2307.03172 — Lost in the Middle: How Language Models Use Long Contexts (Liu et al., TACL 2024); full text via https://ar5iv.labs.arxiv.org/html/2307.03172
|
||||
- Каветы: Extractive retrieval/QA tasks on 2023 models (GPT-3.5, Claude-1.3, MPT-30B, LongChat-13B); the paper says nothing about generation quality vs position. Widely over-generalized in secondary literature to all long-context use.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ /M]** The same paper measured a prompt-layout lever: query-aware contextualization (placing the query both BEFORE and AFTER the long context) took GPT-3.5-Turbo-16K key-value retrieval from a worst case of 45.6% to perfect on 300 pairs — but the paper found it barely changed multi-document QA.
|
||||
- Источник (paper): https://arxiv.org/abs/2307.03172 — Lost in the Middle (Liu et al., TACL 2024)
|
||||
- Каветы: Effect proven on synthetic key-value retrieval; minimal effect on QA; untested for translation. Treat instruction-repetition after the chunk as a cheap hypothesis to A/B, not established fact.
|
||||
- **[LB/M]** RULER (Hsieh et al., 2024) showed effective context length is far below advertised: of 17 models all claiming >=32K context, only about half maintained satisfactory performance at 32K on its 13 tasks (retrieval variants, multi-hop tracing, aggregation), despite near-perfect scores on vanilla needle-in-a-haystack.
|
||||
- Источник (paper): https://arxiv.org/abs/2404.06654 — RULER: What's the Real Context Size of Your Long-Context Language Models?
|
||||
- Каветы: 2024 open and closed models; synthetic tasks. Establishes the 'advertised != effective' principle, not translation-specific numbers.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** NoLiMa (Adobe Research, 2025) showed degradation is much worse when the query and the relevant text share minimal lexical overlap (association must be inferred): of 13 models claiming >=128K context, 11 dropped below 50% of their short-context baseline at 32K; GPT-4o fell from 99.3% to 69.7%; GPT-4.1's effective length (>=85% of base score) was ~16K vs a claimed 1M; Gemini 2.0 Flash dropped to 16.4% at 128K.
|
||||
- Источник (paper): https://arxiv.org/abs/2502.05167 — NoLiMa: Long-Context Evaluation Beyond Literal Matching; effective-length table at https://github.com/adobe-research/NoLiMa
|
||||
- Каветы: Needle-retrieval task, not generation. Highly relevant anyway: cross-lingual glossary/memory lookups are inherently low-lexical-overlap matches, the exact regime NoLiMa shows collapses fastest.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Chroma's 'Context Rot' report (July 2025) tested 18 then-current models (Claude 4 Opus/Sonnet, Gemini 2.5 Pro/Flash, o3, GPT-4.1 family, Qwen3) and found all still degrade non-uniformly as input grows, well before documented limits; counterintuitively, models performed BETTER on shuffled haystacks than on logically coherent ones, and low needle-question similarity amplified length degradation.
|
||||
- Источник (practitioner): https://research.trychroma.com/context-rot — Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma, Hong/Troynikov/Huber)
|
||||
- Каветы: Company research report, not peer-reviewed; single origin voice despite many blogs citing it. Answers the 'do 2025 frontier models still degrade mid-context' question: yes, though less than 2023 models.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Chroma's Repeated Words task is direct long-OUTPUT evidence on 2025 frontier models: asked to replicate text where output length scales with input (up to 10,000 words), all 18 models degraded with length, placed a unique word correctly more reliably when it appeared early, and at long lengths frequently under-generated or hallucinated.
|
||||
- Источник (practitioner): https://research.trychroma.com/context-rot — Context Rot (Chroma, 2025)
|
||||
- Каветы: Verbatim replication is a proxy, not translation; but it is the closest published analog to 'output must be input-sized', which is the translation-chunk regime.
|
||||
- **VERDICT: OVERSTATED** — коррекция: Chroma's Repeated Words task (Context Rot, 2025) is direct long-output evidence: models replicate text whose output length is directly proportional to input length (inputs up to 10,000 words). Among the models evaluated on this task — a subset of the report's 18 LLMs, since o3 and GPT-3.5 turbo were excluded — performance consistently degraded as length increased; accuracy was highest when the unique word appeared near the beginning of the sequence (especially at longer inputs); and at long lengths models often under-generated (repeating words until hitting the output token limit) or produced random words not present in the input.
|
||||
- **[LB/M]** Fiction.LiveBench (narrative deep-comprehension over stories, the closest input-side benchmark to fiction translation) shows accuracy sliding well before the max window — typically from ~32K — with only a few models (Gemini 2.5 Pro, GPT-5, Grok 4 reported) holding good accuracy at 192K, while e.g. DeepSeek V3.1 and Claude Sonnet 4 (thinking) dropped by ~120K.
|
||||
- Источник (blog): https://epoch.ai/benchmarks/fictionlivebench — Fiction.liveBench (Epoch AI mirror) and https://eval.16x.engineer/blog/llm-context-management-guide — LLM Context Management (16x, blog)
|
||||
- Каветы: All reports trace to the single Fiction.live leaderboard (one voice); methodology is only partially public and not peer-reviewed. I could not extract the exact per-model accuracy table. Comprehension task, not generation.
|
||||
- **[ ]** 2026 theory work argues the U-shaped position bias is architectural — present at initialization and not removed by standard training: causal masking concentrates gradient influence at the prompt start and residual connections anchor the final token, leaving a structurally disfavored middle — so mid-context weakness should be engineered around, not waited out.
|
||||
- Источник (paper): https://arxiv.org/abs/2603.10123 — Lost in the Middle at Birth: An Exact Theory of Transformer Position Bias; also https://arxiv.org/html/2602.16837v2 — A Structural Theory of Position Bias in Transformers
|
||||
- Каветы: Theoretical analyses on small/untrained models (GPT-2, Qwen2 scale); corroborates but does not measure frontier-model behavior.
|
||||
- **[LB/M]** For translation specifically, quality degrades with document length and the degradation concentrates in LATER sentences: Pombal-adjacent work (Herold et al. style; arXiv 2412.17592) measured NLLB-600M losing ~10 d-BLEU and ~0.2 COMET translating 256-token documents vs isolated sentences, quality systematically lower for sentences deeper in the document, and degenerate 10-gram repetition loops rising from 4% of pseudo-documents at 256 tokens to 81% at 2048 tokens.
|
||||
- Источник (paper): https://arxiv.org/abs/2412.17592 — Investigating Length Issues in Document-level Machine Translation (full text https://arxiv.org/html/2412.17592v2)
|
||||
- Каветы: Models are NLLB-200-600M (encoder-decoder) and TowerBase-7B — far below the pipeline's model class; TED-talk domain, not literary zh->ru. Direction of effect (late-chunk degradation, repetition onset past training-length) is the transferable part, not the absolute thresholds.
|
||||
- **[LB/M]** SEGALE (arXiv 2509.17249, book-length MT evaluation) measured seven open-weight LLMs translating long documents: most exhibited sharp quality degradation at 4K or 8K context; EuroLLM-9B at 4K stopped translating and summarized instead; under-/over-translation (omission) errors played a significant role in the degradation; Qwen2.5-72B-Instruct was the exception, stable (slightly improving) up to 4K.
|
||||
- Источник (paper): https://arxiv.org/html/2509.17249v1 — Extending Automatic Machine Translation Evaluation to Book-Length Documents (SEGALE)
|
||||
- Каветы: Open-weight models up to 72B, not frontier API models (no DeepSeek V4/GLM-5/Gemini numbers); still the most direct published quality-vs-chunk-size measurement for translation. Larger/stronger models (Qwen-72B) visibly push the cliff outward.
|
||||
- **[LB/M]** LongWriter (arXiv 2408.07055) measured a hard output-length ceiling in 2024-era aligned models: models accepting 100K-token inputs struggled to generate beyond ~2,000 words, traced to scarcity of long outputs in SFT data, and fixable by adding long-output SFT examples (scaling coherent output past 10,000 words).
|
||||
- Источник (paper): https://arxiv.org/abs/2408.07055 — LongWriter: Unleashing 10,000+ Word Generation from Long Context LLMs
|
||||
- Каветы: Measured on 2024 models (GLM-4, GPT-4o era) with open-ended writing tasks; 2026 frontier models have raised caps and long-output tuning, so the exact 2K-word ceiling should not be assumed — but the asymmetry (usable output << usable input) is corroborated by LongProc and Chroma on newer models.
|
||||
- **[LB/M]** LongProc (Princeton, arXiv 2501.05414) measured long structured GENERATION with rule-based scoring on 17 models at 500/2K/8K output tokens: open-weight models typically faltered already at 2K-token outputs, and even closed models like GPT-4o showed significant degradation at 8K-token outputs, despite all claiming >32K context windows.
|
||||
- Источник (paper): https://arxiv.org/abs/2501.05414 — LongProc: Benchmarking Long-Context Language Models on Long Procedural Generation; https://pli.princeton.edu/blog/2025/long-input-long-output-holistic-long-context-evaluation-helmet-and-longproc
|
||||
- Каветы: Procedural/structured tasks (TSV extraction, travel planning), not translation; GPT-4o-era closed models. Best available bound on 'useful output tokens per call' for quality-sensitive generation.
|
||||
- **[LB/M]** Documented provider output caps for the pipeline's model class (retrieved July 2026) are far above the quality-degradation thresholds: DeepSeek v4-flash/pro — 1M context, max output 384K tokens (official docs; deepseek-chat/reasoner aliases deprecated 2026-07-24); Gemini 2.5 Pro — input limit 1,048,576, output limit 65,536 (official docs); GLM-5.2 — 1M context, up to 131,072 output tokens (vendor-adjacent listings).
|
||||
- Источник (official-doc): https://api-docs.deepseek.com/quick_start/pricing — DeepSeek API docs; https://ai.google.dev/gemini-api/docs/models/gemini-2.5-pro — Gemini API docs; https://openrouter.ai/z-ai/glm-5.2 and https://www.marktechpost.com/2026/06/14/z-ai-launches-glm-5-2-with-a-usable-1m-token-context-two-thinking-effort-levels-and-no-benchmarks-at-launch/ — GLM-5.2 listings
|
||||
- Каветы: GLM-5.2 figure is from OpenRouter/press coverage, not fetched directly from docs.z.ai — verify against the live z.ai model page before hardcoding. Documented caps are ceilings on what the API accepts, NOT usable-quality lengths (LongProc/LongWriter show quality decays orders of magnitude below these caps).
|
||||
- **[ ]** The field's literary-translation evaluation standard (WMT24 Discourse-Level Literary Translation, GuoFeng webnovel corpus, zh->en/de/ru) treats one webnovel CHAPTER as the document unit, with official ranking by human judgment over ~20 consecutive chapters per book — i.e., chapter-level coherence, not sentence-level metrics, is the accepted quality frame for this exact domain.
|
||||
- Источник (paper): https://arxiv.org/html/2412.11732v1 — Findings of the WMT 2024 Shared Task on Discourse-Level Literary Translation
|
||||
- Каветы: Setup/context claim, not a degradation number; the zh->de and zh->ru references were produced by GPT-4 translation plus human post-editing, so zh->ru 'gold' data there is machine-flavored.
|
||||
|
||||
## t6-cat-practice — How professional translation practice handles segmentation and context: SRX, translation units, CAT
|
||||
|
||||
- **[ ]** SRX (Segmentation Rules eXchange) is an XML-based standard (OSCAR 1.0 in 2004, 2.0 in 2008; maintained by GALA after LISA's 2011 insolvency) that defines segmentation as ordered ICU-regex break/exception rules; it was created because tools segmented text differently, making TMX exchange unreliable.
|
||||
- Источник (standard): https://en.wikipedia.org/wiki/Segmentation_Rules_eXchange (Segmentation Rules eXchange — Wikipedia); see also https://www.gala-global.org/srx-10 (SRX 1.0 | GALA Global)
|
||||
- Каветы: Default rules break on full stop/colon/question/exclamation marks with exception patterns — i.e., sentence-level is the industry default unit. This validates that deterministic regex-driven segmentation without model calls is exactly how the industry itself does it.
|
||||
- **[LB]** The classic criticism of sentence-level TM/CAT segmentation is loss of text-level cohesion: Heyn's (1998) 'peephole' effect (translators avoid intratextual references so segments stay reusable) and the 'sentence-salad' effect (incoherent text assembled from segments), plus the observation that translators start working 'mechanically sentence-by-sentence, instead of focusing on how each sentence relates to those around it and to the text as a whole'; TM has therefore 'not been considered appropriate for literary or creative texts'.
|
||||
- Источник (paper): https://en.wikipedia.org/wiki/Translation_memory (Translation memory — Wikipedia, summarizing Heyn 1998 and later scholarship); Heyn primary: https://aclanthology.org/www.mt-archive.info/90/DCU-1998-Heyn.pdf
|
||||
- Каветы: Multiple secondary sources (Wikipedia, an EN→AR cohesion study, literary-PE papers) all trace the peephole/sentence-salad framing to ONE origin, Heyn 1998 — one voice, widely accepted. Heyn's primary PDF could not be text-extracted in this session; quotes are via the Wikipedia summary.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** In the only controlled study found directly on point (Vieira, Zelenka, Youdale, Zhang & Carl 2023, Translation & Interpreting 15(1)): English→Chinese post-editing of science-fiction short stories in Trados Studio compared sentence-based vs paragraph-based presentation; paragraph segmentation was associated with lower technical (editing) effort on average, MT assistance did not substantially shorten translation time, and inter-translator variation was large.
|
||||
- Источник (paper): https://www.trans-int.org/index.php/transint/article/view/1389 (Translating science fiction in a CAT tool: machine translation and segmentation settings — Vieira et al. 2023)
|
||||
- Каветы: Single study, small N (typical for PE process research), one language pair (EN→ZH — the reverse of your zh→ru direction), sci-fi short stories; exact effect sizes were not retrievable from the abstract page. Do not generalize beyond 'paragraph presentation is at least competitive and likely better for literary PE'.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB]** Vinay & Darbelnet (1958) define the unit of translation as a 'unit of thought' — the smallest segment of the utterance whose signs are so linked that they must not be translated individually — explicitly rejecting the word; later scholarship (Barkhudarov: whole text as unit for poetry; Bassnett: text as prime unit for prose; Koller: the more dissimilar the languages, the larger the unit needed) pushes the literary unit toward paragraph/text level, and larger units are held to yield more idiomatic translation.
|
||||
- Источник (paper): https://en.wikipedia.org/wiki/Translation_unit (Translation unit — Wikipedia, citing Vinay & Darbelnet, Barkhudarov, Bassnett, Koller)
|
||||
- Каветы: Theoretical, not empirical. Koller's point is directly relevant to zh/ja→ru: distant language pairs need larger units, i.e., sentence-aligned chunking is the worst case precisely for CJK→European pairs.
|
||||
- **VERDICT: OVERSTATED** — коррекция: Vinay & Darbelnet (1958; English trans. 1995, p. 21) define the unit of translation — equated with the 'lexicological unit' and 'unit of thought' — as "the smallest segment of the utterance whose signs are linked in such a way that they should not be translated individually" (per Munday/Hatim & Munday; some renderings say "literally"), and per standard translation-studies accounts they reject the word as the unit of translation [source: V&D 1958/1995:21 via Hatim & Munday 2004:138 — NOT the Wikipedia article, which only mentions V&D discussing the single word via Saussure]. Separately, the Wikipedia 'Translation unit' article does support: Barkhudarov (translation unit can be a complete text, e.g. in poetry), Bassnett (text as prime unit for prose), Koller (the more unrelated the languages, the larger the unit), and that larger translation units give a better chance of idiomatic translation.
|
||||
- **[LB]** CAT tools operationalize 'context' minimally as the immediately adjacent segments: memoQ's official docs define a context match (101%) as a 100% match whose stored previous AND next source segments also match, and a 102% 'double context' match when both text-flow context and structural ID match; context is only checked within one structural unit (e.g., a cell/heading has empty prev/next context at its edges).
|
||||
- Источник (official-doc): https://docs.memoq.com/current/en/Concepts/concepts-double-context-matches.html (memoQ Docs: Double context matches); https://support.phrase.com/hc/en-us/articles/9386879839900-Translation-Memory-Match-Context-TMS (Phrase: Translation Memory Match Context)
|
||||
- Каветы: This is the industry's deterministic floor for context (±1 segment) — useful as a precedent, but it is exactly what literary practice criticizes as insufficient; it also shows 'context stops at structural-unit boundaries' is an established, codifiable rule.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ /M]** Ruffo's survey of 150 literary translators from 35 countries found only ~25% use CAT tools for literary work; attitudes were positive toward generic tools and even TMs (49% positive on technology overall) but negative toward MT/AI, with respondents saying CAT/MT are unsuitable for literary translation because creativity and lexical/syntactic variation are compromised.
|
||||
- Источник (paper): https://benjamins.com/catalog/tris.23015.ruf (Ruffo, 'Literary translators in-between: self-imaging discourse and relationship to technology', Translation in Society); survey figures relayed via https://aclanthology.org/2023.eamt-1.48.pdf (DUAL-T, EAMT 2023)
|
||||
- Каветы: Self-report survey, not performance data; percentages retrieved via search-result summaries of the DUAL-T/Ruffo publications rather than the paywalled full text.
|
||||
- **[LB]** Netflix's Timed Text Style Guide is a production-grade example of deterministic sense-block segmentation: max 42 chars/line, max 2 lines, keep to one line unless over limit, break 'after punctuation marks, before conjunctions, before prepositions', and never separate article from noun, adjective from noun, first from last name, verb from subject pronoun, prepositional verb from its preposition, or verb from auxiliary/reflexive/negation; the general guide adds that subtitles should be segmented at clause level.
|
||||
- Источник (official-doc): https://partnerhelp.netflixstudios.com/hc/en-us/articles/217350977-English-USA-Timed-Text-Style-Guide (Netflix English (USA) Timed Text Style Guide); https://partnerhelp.netflixstudios.com/hc/en-us/articles/215758617-Timed-Text-Style-Guide-General-Requirements
|
||||
- Каветы: Subtitling is a different task (display constraint, not translation-unit choice), but it proves that 'break only at natural linguistic boundaries, expressed as a finite rule list' is an accepted, fully deterministic industry practice — a direct design precedent for rule-based chunk boundary scoring in Go.
|
||||
- **VERDICT: OVERSTATED** — коррекция: Netflix's Timed Text Style Guides prescribe rule-based line treatment: the English (USA) guide sets max 42 characters/line, max 2 lines, keep to one line unless over the limit, break after punctuation marks / before conjunctions / before prepositions, and states the line break should not separate an article from its noun, adjective from noun, first from last name, verb from subject pronoun, prepositional verb from its preposition, or verb from auxiliary/reflexive pronoun/negation. The clause-level rule comes from a separate document — the Subtitle Templates guide (Section 25), which requires that sentences split across multiple subtitle events "are always segmented at a clause level" — not from the General Requirements guide, and neither document uses the term "sense block".
|
||||
- **[LB]** CJK webnovel translation (fan and commercial) is organized around the CHAPTER as the work unit — serialized 1–2 chapters/day on Qidian/JJWXC-style platforms, translated and released chapter-by-chapter on platforms like Wuxiaworld (still the most influential fan-translation platform per Deng 2024) — with a persistent master glossary as the central consistency instrument shared by translator, editor, and proofreader.
|
||||
- Источник (practitioner): https://ccsenet.org/journal/index.php/ells/article/view/0/50960 (Deng, 'Digitalized Translation of Chinese Online Literature: Practice and Research', ELLS 14(4), 2024); https://read.teanovel.com/blog/chinese-web-novel-beginners-guide (TeaNovel blog); https://read.teanovel.com/blog/how-to-translate-chinese-novels-with-ai
|
||||
- Каветы: The chapter-unit and platform facts come from an academic paper (Deng 2024); the glossary-workflow details come from practitioner/marketing blogs (TeaNovel, Lexilit, Artlangs) — consistent with each other but not peer-reviewed ethnography. Academic term-strategy backing: Zhou Ling-fei 2022, 'A Study on the Translation of Terms in Chinese Online Xianxia Novels' (davidpublisher.com), whose PDF could not be text-extracted here.
|
||||
- **[ ]** Terminology 'consistency drift' across chapters (a name or cultivation term rendered differently by chapter 20/47) is described by practitioners as THE defining failure mode of amateur/machine webnovel translation, and tools in this niche compete on glossary managers and pre-analysis passes that lock names/terms before translating.
|
||||
- Источник (blog): https://read.teanovel.com/blog/how-to-translate-chinese-novels-with-ai (TeaNovel: How to Translate Chinese Web Novels with AI); https://lexilit.com/chinese-web-novels-in-english (Lexilit); https://absolutemystery.com/ (AbsoluteMystery — glossary manager)
|
||||
- Каветы: Marketing/practitioner content from tool vendors — self-interested framing, but it converges with the academic finding (DITING) that terminology is a first-class webnovel MT failure axis.
|
||||
- **[ /M]** DITING (Zhang et al., arXiv 2510.09116, 2025), the first evaluation framework specifically for web-novel MT, formalizes six webnovel-specific quality dimensions — idiom translation, lexical ambiguity, terminology localization, tense consistency, zero-pronoun resolution, cultural safety — on 18K+ expert-annotated zh-en sentence pairs; among 14 models, Chinese-trained LLMs outperformed larger foreign models and DeepSeek-V3 was most faithful/stylistically coherent.
|
||||
- Источник (paper): https://arxiv.org/abs/2510.09116 (DITING: A Multi-Agent Evaluation Framework for Benchmarking Web Novel Translation)
|
||||
- Каветы: zh→EN, not zh→RU; benchmark is sentence-pair based, so it measures error types (zero pronouns, terminology) rather than chunking policy; single paper, not yet independently replicated. Its dimension list is still the best available checklist of what chunk-level context must preserve.
|
||||
- **[LB]** Chinese and English differ in paragraph organization and dialogue layout: in Chinese fiction dialogue is often embedded inside narrative paragraphs, while English convention (Chicago-style craft guidance) starts a new paragraph per speaker; translation-studies work on Chinese fiction states translators must consider target-language habits and split/merge paragraphs accordingly, moving dialogue into separate paragraphs for visual clarity.
|
||||
- Источник (paper): https://francis-press.com/uploads/papers/WI0KQ8v2FJkqnyR5PZ7DVvnwUwfjYFBqicwVp9n8.pdf (A Study on Translation of Jin Yong's Novels, Francis Press); English convention: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Quotations/faq0029.html (CMOS Q&A: Quotations and Dialogue)
|
||||
- Каветы: WEAKEST-SOURCED load-bearing claim in this report: the Jin Yong paper PDF would not text-extract, so the quote comes from a search-result synthesis over that paper and an IJRAR paper (https://ijrar.org/papers/IJRAR22A2283.pdf); treat direction (re-paragraphing is normal, expected translator work) as solid, exact wording as unverified.
|
||||
- **[LB]** Chinese webnovels are written mobile-first with very short, left-aligned paragraphs and heavy white space (serialized scrolling platforms), so their paragraph rhythm is a platform artifact, not an authorial prose unit — meaning source paragraph boundaries in webnovels are dense, shallow signals rather than European-style discourse paragraphs.
|
||||
- Источник (practitioner): https://www.scribblehubforum.com/threads/what-is-the-webnovel-format-compared-to-a-standard-novel-format.24463/ (Scribble Hub forum); https://en.wikipedia.org/wiki/Chinese_online_literature (Chinese online literature — Wikipedia); https://read.teanovel.com/blog/chinese-web-novel-beginners-guide
|
||||
- Каветы: Community/practitioner sources; no quantitative corpus study of webnovel paragraph length found. Implication cuts both ways: short paragraphs give many candidate chunk boundaries, but a single paragraph is far below a sensible translation unit.
|
||||
- **[LB]** Japanese fiction formats each dialogue utterance in 「」 kagikakko, typically starting on its own line without indent, with terminal punctuation inside the bracket and frequently NO speaker attribution — readers infer speakers from register, sentence-final particles, and gendered speech; translators into European languages must decide whether to add attributions (Murakami is noted for atypically heavy tag use giving a 'foreign feel').
|
||||
- Источник (practitioner): https://hinative.com/questions/3192930 (HiNative: dialogue in Japanese books); https://note.com/kanna3939/n/nc43eebe822d6?hl=en (Japanese Literary Fiction Writing Guidelines); https://www.japantimes.co.jp/life/2018/05/14/language/whose-line-anyway-tips-deciphering-dialogue-japanese-fiction/ (Japan Times: Whose line is it anyway?)
|
||||
- Каветы: Japan Times article returned 403; its content is cited from the search snippet only. All sources are practitioner-level (language-learning/writing communities), but they agree; no contradicting source found. For chunking this means ja dialogue runs are visually line-per-utterance and speaker identity is carried by long-range context, not local text.
|
||||
- **[ /M]** Empirical follow-up exists for the cohesion criticism: a journal study specifically measured the impact of TM sentence segmentation on cohesion and coherence of EN→AR technical translations, explicitly building on the peephole/sentence-salad effects — i.e., the segmentation-cohesion link is treated as a testable degradation, not just an opinion.
|
||||
- Источник (paper): https://jwadi.journals.ekb.eg/article_268202.html (The Impact of Translation Memory Segmentation on the Cohesion and Coherence of Technical Texts Translated from English into Arabic)
|
||||
- Каветы: Article page failed to load (socket hang up); claim rests on the search-result snippet and title. Technical texts, not literary; EN→AR. Counts as corroboration of the Heyn line, but it is still downstream of the same single origin.
|
||||
|
||||
## t7-caching — Official provider documentation on prompt caching mechanics and pricing (Anthropic, OpenAI, DeepSeek
|
||||
|
||||
- **[LB]** Anthropic prompt caching hashes the request prefix in the fixed order tools -> system -> messages, requires 100% identical content up to the cache_control block, and changes at one level invalidate that level and everything after it.
|
||||
- Источник (official-doc): https://platform.claude.com/docs/en/build-with-claude/prompt-caching.md — Anthropic Docs: Prompt caching
|
||||
- Каветы: Hierarchy detail: tool_choice/image/thinking changes invalidate only the messages tier; tool-definition or model changes invalidate everything.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB]** On Anthropic, cache writes happen ONLY at explicit cache_control breakpoints (max 4 per request); on later requests the system walks backward at most 20 blocks from each breakpoint looking for previously WRITTEN entries — so a breakpoint placed on a block that changes every call (e.g., a running summary) produces zero cache hits; the breakpoint must sit on the last STABLE block.
|
||||
- Источник (official-doc): https://platform.claude.com/docs/en/build-with-claude/prompt-caching.md — Anthropic Docs: Prompt caching
|
||||
- Каветы: This directly answers key question (1) for Anthropic: a changing running summary at the end leaves everything before it cacheable, but only if the breakpoint is on the last stable block, not auto-placed on the final (volatile) block. The doc's worked 'common mistake' example is exactly the changing-suffix case.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Anthropic caching pricing: 5-minute-TTL cache writes cost 1.25x base input price, 1-hour-TTL writes cost 2x, cache reads cost 0.1x; reading cached content refreshes its TTL at no additional cost.
|
||||
- Источник (official-doc): https://platform.claude.com/docs/en/build-with-claude/prompt-caching.md — Anthropic Docs: Prompt caching
|
||||
- Каветы: Break-even math: 5m TTL pays off from the 2nd hit; 1h TTL needs more reuse. Free refresh-on-use means a steady sequential chunk pipeline keeps the 5m cache alive indefinitely.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Anthropic minimum cacheable prompt length is model-dependent (per the live doc: 512 tokens for Claude Fable 5; 1,024 for Opus 4.8/Sonnet 5/Sonnet 4.6/4.5; 2,048 for Opus 4.7; 4,096 for Opus 4.6/4.5 and Haiku 4.5); shorter prompts are silently processed without caching, with no error.
|
||||
- Источник (official-doc): https://platform.claude.com/docs/en/build-with-claude/prompt-caching.md — Anthropic Docs: Prompt caching
|
||||
- Каветы: Verbatim table re-extracted twice with identical values, but this table visibly changes across model generations (an older cached copy of the same doc showed different per-model values) — treat the exact numbers as volatile and re-check before hardcoding; the design-stable fact is 'minimum is ~512–4,096 tokens and failure is silent — verify via usage.cache_read_input_tokens'.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB]** An Anthropic cache entry becomes available only after the first response BEGINS; parallel requests with identical prefixes all pay full (write) price, so fan-out should wait for the first response before firing the rest. This also bounds retry economics: a retry of a request that failed before the response began pays the cache-write price again (no entry was written), while a retry after a mid-stream failure or completed-but-rejected generation reads the prefix at 0.1x.
|
||||
- Источник (official-doc): https://platform.claude.com/docs/en/build-with-claude/prompt-caching.md — Anthropic Docs: Prompt caching
|
||||
- Каветы: The second sentence of the claim (retry billing split) is my inference from the quoted timing rule plus the read/write multipliers — no provider doc states error-path cache billing explicitly. Anthropic also never bills a 'retry' specially: the retry is an ordinary request billed as read(prefix)+input(suffix) or write+input.
|
||||
- **VERDICT: OVERSTATED** — коррекция: Per Anthropic's prompt-caching docs, a cache entry only becomes available after the first response begins, so concurrent requests with identical prefixes will not get cache hits from each other's in-flight writes; for cache hits on parallel fan-out, wait for the first response before sending subsequent requests. Cache reads bill at 0.1x base input price and 5-minute-TTL cache writes at 1.25x (1-hour: 2x). The retry-economics corollary — that a retry of a request failing before the response began re-pays the cache-write price, while a retry after a mid-stream failure or rejected generation reads the prefix at 0.1x — is an inference from this sentence, not something the documentation states.
|
||||
- **[LB/M]** OpenAI prompt caching is fully automatic (no code changes, no cache_control equivalent) on gpt-4o and newer, applies only to prompts of 1024+ tokens, and requires exact prefix matches; routing uses a hash of roughly the first 256 tokens, optionally steered with the prompt_cache_key parameter.
|
||||
- Источник (official-doc): https://developers.openai.com/api/docs/guides/prompt-caching — OpenAI Docs: Prompt caching
|
||||
- Каветы: Because there are no breakpoints, OpenAI answers question (1) implicitly: the cacheable prefix is simply the longest exact-matching prefix, so a changing summary at the end truncates the hit there automatically — no placement bug is possible, unlike Anthropic. Cached-token count is reported in usage prompt_tokens_details.cached_tokens.
|
||||
- **[LB]** OpenAI explicitly instructs the static-before-dynamic ordering: put instructions/examples at the beginning and variable, user-specific content at the end; images and tools must be byte-identical to count toward the prefix.
|
||||
- Источник (official-doc): https://developers.openai.com/api/docs/guides/prompt-caching — OpenAI Docs: Prompt caching
|
||||
- Каветы: This is the direct official answer to key question (2), and it matches Anthropic's and Gemini's guidance — three providers independently prescribe the same layout, so the ordering rule is provider-portable.
|
||||
- **[LB/M]** OpenAI cache economics (per live 2026 pricing page): cached input tokens are billed at 10% of the standard input rate (90% discount) across current models offering caching (e.g., gpt-5.4: $2.50 input / $0.25 cached); on pre-GPT-5.6 models cache writes are free, while GPT-5.6+ introduces 1.25x-priced cache writes and an optional prompt_cache_options.ttl of '30m'; default retention is 5–10 minutes of inactivity, up to 1 hour (24h on select extended-retention models).
|
||||
- Источник (official-doc): https://developers.openai.com/api/docs/pricing and https://developers.openai.com/api/docs/guides/prompt-caching — OpenAI Docs: Pricing; Prompt caching
|
||||
- Каветы: The 90% figure is computed from the pricing table (cached price / input price), consistent across listed models; some pro-tier models list no caching at all. Model names (gpt-5.4/5.5/5.6) are post-training-cutoff and taken as extracted from the live page. OpenAI docs say nothing about failed-request billing or whether an errored request populates the cache.
|
||||
- **[LB]** DeepSeek context caching on disk is enabled by default for all users with no code changes; a request is a cache hit only for prefixes identical from token 0; storage granularity is 64-token units (content under 64 tokens is never cached); hits/misses are reported per request as prompt_cache_hit_tokens / prompt_cache_miss_tokens; the cache is best-effort with no guaranteed hit rate, and unused entries are cleared 'within a few hours to a few days'.
|
||||
- Источник (official-doc): https://api-docs.deepseek.com/guides/kv_cache and https://api-docs.deepseek.com/news/news0802 — DeepSeek API Docs: Context Caching; DeepSeek API introduces Context Caching on Disk
|
||||
- Каветы: For question (1): a changing running summary near the end truncates the hit at the last identical 64-token boundary; everything before caches automatically. The kv_cache guide adds that cache units are carved at the end of user input and end of model output plus fixed token intervals, which is what makes multi-turn/next-chunk reuse work. Per-user cache isolation is explicit ('logically invisible to others').
|
||||
- **[LB/M]** DeepSeek current pricing (live page, July 2026): deepseek-v4-flash — $0.0028/M input on cache hit, $0.14/M on cache miss, $0.28/M output; deepseek-v4-pro — $0.003625/M hit, $0.435/M miss, $0.87/M output; legacy names deepseek-chat and deepseek-reasoner are deprecated on 2026-07-24 and map to v4-flash modes.
|
||||
- Источник (official-doc): https://api-docs.deepseek.com/quick_start/pricing — DeepSeek API Docs: Models & Pricing
|
||||
- Каветы: Hit prices imply a ~98–99% discount vs miss — far deeper than the historical 90% ($0.014 vs $0.14 at the 2024 launch). Extracted twice with identical digits, but both extractions came from one page fetch through a summarizing layer; re-verify these exact hit prices against the live page before baking them into a COGS model. The deprecation date is 8 days after today — model-slug migration is urgent for any DeepSeek-calling code.
|
||||
- **[LB/M]** Gemini implicit caching is enabled by default for all Gemini 2.5+ models with no guarantee of savings; minimum input for a hit is 2,048 tokens (2.5 Flash/Pro) or 4,096 tokens (3.x-generation models); Google's official guidance is to put large common content at the beginning of the prompt and to send similar-prefix requests close together in time; cached-token counts appear in usage metadata (cached_content_token_count / total_cached_tokens depending on API surface).
|
||||
- Источник (official-doc): https://ai.google.dev/gemini-api/docs/generate-content/caching and https://ai.google.dev/gemini-api/docs/caching — Google AI for Developers: Context caching
|
||||
- Каветы: Google's docs split by API surface in 2026: the new Interactions API supports implicit caching only, while the legacy Generate Content API supports both implicit and explicit. 'Send requests with similar prefix in a short amount of time' is the same warm-cache-sequentially advice as Anthropic's concurrent-request rule, stated softly.
|
||||
- **[LB/M]** Gemini explicit caching (caches.create / CachedContent on the Generate Content API) has a default TTL of 1 hour with no min/max bounds, carries a cost-saving GUARANTEE (unlike implicit), and bills three components: cached tokens at a reduced rate (~10% of standard input, e.g. 2.5 Pro $0.125/M cached vs $1.25/M input), storage per token-hour ($4.50/M-tok/hr for 2.5 Pro, $1.00/M-tok/hr for Flash-tier models), plus normal rates for non-cached input and output.
|
||||
- Источник (official-doc): https://ai.google.dev/gemini-api/docs/generate-content/caching and https://ai.google.dev/gemini-api/docs/pricing — Google AI for Developers: Context caching; Gemini Developer API pricing
|
||||
- Каветы: Storage is billed on wall-clock TTL duration regardless of use — unlike Anthropic (free refresh-on-use) and OpenAI/DeepSeek (no storage charge at all), so explicit Gemini caches only pay off for heavily reused static content (a book-wide system prompt + glossary fits; per-chunk content does not). CachedContent fields (model, contents, tools, systemInstruction) are immutable after creation.
|
||||
- **[LB]** No provider's official caching documentation states what is billed when a generation FAILS or is REJECTED and then retried; retry cost must be derived from the general rules: the retry is billed as a normal request, with the identical prefix billed at cache-read rates only if (a) the prior attempt progressed far enough to write the cache (Anthropic: response began; others: unspecified), (b) the retry arrives within the retention window (Anthropic 5m/1h; OpenAI 5–10m; DeepSeek best-effort hours-days; Gemini implicit unspecified / explicit TTL), and (c) the retry body is byte-identical.
|
||||
- Источник (official-doc): https://platform.claude.com/docs/en/build-with-claude/prompt-caching.md (plus the OpenAI, DeepSeek, Gemini caching pages cited above) — Anthropic Docs: Prompt caching
|
||||
- Каветы: This is a synthesis finding: the quoted Anthropic sentence is the only official statement that constrains the failure/retry path; the rest is inference from documented mechanics, flagged as such. Practical consequence: a judge-rejected translation retried with the identical prompt is cheap (prefix at 0.1x/10%/hit-rate pricing), but a retry that MODIFIES the prompt (e.g., appending 'previous attempt was rejected because...') invalidates from the edit point onward.
|
||||
|
||||
## t8-memory-state — Sequential whole-book processing with LLMs: recursive summarization error accumulation, running-summ
|
||||
|
||||
- **[LB/M]** In recursive book summarization (GPT-3 175B, RLHF), errors made in lower-level summaries compound at each composition step: full-book Likert scores were significantly lower than scores of any individual decomposed subtask.
|
||||
- Источник (paper): https://arxiv.org/abs/2109.10862 — Wu et al. 2021, "Recursively Summarizing Books with Human Feedback" (OpenAI)
|
||||
- Каветы: 2021 GPT-3-era models; absolute magnitudes are likely better with modern models, but the structural point (hierarchical composition propagates lower-level errors upward) is architecture-level, not model-level.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ /M]** Even the best recursive-summarization model produced human-comparable book summaries rarely: ~5% of books rated 6/7 and >15% rated 5/7, significantly below human-written summaries on average.
|
||||
- Источник (paper): https://arxiv.org/abs/2109.10862 — Wu et al. 2021, "Recursively Summarizing Books with Human Feedback"
|
||||
- Каветы: Calibration data point for 2021-era models only; not a statement about current models.
|
||||
- **[LB/M]** Incrementally updating a running summary chunk-by-chunk produces measurably less coherent book summaries than hierarchical chunk-summarize-then-merge, across models: GPT-4 82.5 vs 89.1 BooookScore, GPT-3.5-Turbo 67.0 vs 84.2, Mixtral-8x7B 64.5 vs 81.5; the gap closes only with very large chunks (Claude 2 at 88K-token chunks: 90.9 incremental vs 90.3 hierarchical).
|
||||
- Источник (paper): https://arxiv.org/abs/2310.00785 — Chang et al., "BooookScore: A systematic exploration of book-length summarization in the era of LLMs" (ICLR 2024)
|
||||
- Каветы: BooookScore measures coherence of the summary text (1193 human annotations on 100 books, 8 error types), NOT faithfulness to the source book; incremental updating retained more detail. 2023/24 models.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Omission is the dominant error class in book-length summarization, and running-summary (incremental) updating roughly doubles per-sentence error rates vs hierarchical merging: entity omission 7.3% vs 3.71%, event omission 4.25% vs 2.27%, causal omission 2.75% vs 1.21%, duplication 2.12% vs 1.18%.
|
||||
- Источник (paper): https://arxiv.org/html/2310.00785v4 — BooookScore (ICLR 2024), Table 1
|
||||
- Каветы: Rates are per-sentence over GPT-4 summaries of 100 books; 'compounding omission' is the endpoint measurement — the paper does not plot error rate as a function of update count.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Recursive merging of summaries without source access amplifies hallucination; re-grounding merge steps with extracted source context measurably improves faithfulness: manual claim-accuracy 72.7% vs 59.1% for vanilla hierarchical merging, and AlignScore 85.8 vs 76.3 (Llama-3.1-70B, Multi-LexSum).
|
||||
- Источник (paper): https://arxiv.org/abs/2502.00977 — Ou & Lapata 2025, "Context-Aware Hierarchical Merging for Long Document Summarization"
|
||||
- Каветы: Manual evaluation was on one book only; automatic faithfulness metrics (AlignScore/SummaC) are themselves noisy. Tested on legal/gov/book summarization, not translation.
|
||||
- **VERDICT: OVERSTATED** — коррекция: Recursive merging of summaries can amplify LLM hallucinations; enriching merge steps with source-document context measurably improves faithfulness (Ou & Lapata 2025). On Multi-LexSum with Llama-3.1-70B, all context-aware variants beat vanilla hierarchical merging (AlignScore 76.3): citation-based Cite-Replace is best at 85.8, while extraction-based variants reach 79.0–79.9. Separately, a small manual claim-accuracy study on one SuperSummary book (Llama-3.1-70B) found 72.7% correct claims for Extract-Support vs 59.1% for vanilla hierarchical merging.
|
||||
- **[LB/M]** OS-style paged memory with structured, agent-editable state (MemGPT: core memory blocks + append-only recall storage + archival store) held consistency where fixed-context baselines collapsed: deep memory retrieval accuracy 92.5% vs 32.1% (GPT-4), 93.4% vs 35.3% (GPT-4 Turbo), and nested key-value multi-hop lookup where fixed-context baselines hit 0% at 3+ nesting levels.
|
||||
- Источник (paper): https://arxiv.org/abs/2310.08560 — Packer et al. 2023, "MemGPT: Towards LLMs as Operating Systems"
|
||||
- Каветы: Evaluated on multi-session dialogue and document QA, not translation or narrative generation; 2023 GPT-3.5/GPT-4. MemGPT's memory paging is LLM-driven, not deterministic — later work notes its naive summary-merge itself drifts. Letta docs page (docs.letta.com/memory/overview) returned 404, so current vendor framing unverified.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Memory representation should match query type: free-prose summaries and raw chunks win on long-context comprehension (summaries best on NarrativeQA F1 32.93%, chunks best on QuALITY 78.5%), while structured atomic facts/knowledge triples win on precise relational lookup, and mixed memory is the most noise-robust (F1 82.11% on HotpotQA).
|
||||
- Источник (paper): https://arxiv.org/abs/2412.15266 — Zeng et al. 2024, "On the Structural Memory of LLM Agents"
|
||||
- Каветы: QA/dialogue benchmarks, not generation or translation; 'summary vs structured' trade-off measured for retrieval accuracy, not for state-update drift.
|
||||
- **[LB/M]** A deterministic bilingual term record (dictionary of each proper noun's FIRST translation, injected as a constraint into every subsequent sentence prompt) is a measured fix for name/term drift: DelTA raises lexical translation consistency (LTCR-1) by up to 4.58pp on main test sets and from 37.00 to 85.50 (+48.5pp) on the GuoFeng webnovel set, while also raising COMET by up to 3.16.
|
||||
- Источник (paper): https://arxiv.org/abs/2410.08143 — Wang et al., "DelTA: An Online Document-Level Translation Agent Based on Multi-Level Memory" (ICLR 2025)
|
||||
- Каветы: LTCR-1 defines consistency as matching the FIRST translation — it rewards lock-in, not correctness of the first choice; a wrong first translation is propagated (summary-poisoning analog). En↔Zh/De etc., not →ru. Same broader author line (Longyue Wang / Tencent) as the GuoFeng corpus — partially one voice with the BWB/doc-MT findings.
|
||||
- **[LB/M]** Window/chunk-based whole-document LLM translation loses sentences as windows grow: with a 50-sentence window the baseline dropped 10 target sentences despite complete source input; DelTA's sentence-by-sentence strategy with memory avoided omissions entirely.
|
||||
- Источник (paper): https://arxiv.org/html/2410.08143v1 — DelTA (ICLR 2025)
|
||||
- Каветы: Small-scale illustration within one paper; exact omission-vs-window-size curve not published. Sentence-by-sentence translation trades throughput and paragraph-level fluency for coverage.
|
||||
- **[LB/M]** Giving the translator paragraph-level context sharply reduces consistency errors vs sentence-by-sentence translation: 2 vs 25 inconsistency errors, 480 vs 622 mistranslations, 102 vs 156 grammar errors (GPT-3.5, 18 language pairs incl. zh/ja/ru sources), and translators preferred paragraph-level 71.1% of the time — yet critical errors persist and paragraph mode occasionally omits content.
|
||||
- Источник (paper): https://arxiv.org/abs/2304.03245 — Karpinska & Iyyer 2023, "Large language models effectively leverage document-level context for literary translation, but critical errors persist"
|
||||
- Каветы: GPT-3.5 (2023); context = one paragraph, not cross-chapter state, so it does not measure book-scale consistency; error counts are totals over the study corpus, not rates per length.
|
||||
- **[LB/M]** In Chinese web-novel document-level MT specifically, named entities and terminology are the dominant document-level failure: 43.3% of document-level errors were named-entity mistranslations and 19.2% terminology mistakes; document-level MT coreference F1 was 63.5 vs 88.1 for humans (B3).
|
||||
- Источник (paper): https://arxiv.org/abs/2305.11142 — "Discourse Centric Evaluation of Machine Translation with a Densely Annotated Parallel Corpus" (BWB corpus, 6 web novels)
|
||||
- Каветы: zh→en web novels — closest published genre match to ranobe/webnovel work, but not →ru; pre-LLM-era NMT systems in some comparisons. Overlaps in authorship with the Tencent doc-MT line — count as partially one voice with DelTA/GuoFeng.
|
||||
- **[ /M]** The append-only event log + periodic synthesized reflection pattern is measurably better than reflection-free memory: full architecture TrueSkill mu=29.89 vs 26.88 without reflection vs 21.21 with observations/reflection/planning all removed (effect size d=8.16 vs prior-work baseline).
|
||||
- Источник (paper): https://arxiv.org/abs/2304.03442 — Park et al. 2023, "Generative Agents: Interactive Simulacra of Human Behavior"
|
||||
- Каветы: Measured on believability of simulated social agents — far from translation; supports the append-only-log + periodic-consolidation pattern only at the architecture level.
|
||||
- **[ /M]** Reported claims that agent memory drifts catastrophically over hundreds of interactions (e.g., 42% task-success reduction beyond ~200-300 interactions; iterative lossy re-summarization progressively distorting stored facts) circulate in 2026 preprints/surveys but I could only verify them via secondary aggregators, not primary texts.
|
||||
- Источник (blog): https://www.emergentmind.com/papers/2601.04170 — "Quantifying Agent Drift in Multi-Agent LLMs" (aggregator summary); https://arxiv.org/pdf/2603.11768 — SSGM framework preprint
|
||||
- Каветы: UNVERIFIED against the primary paper; treat as directional only. The qualitative mechanism (repeated lossy re-encoding distorts state) is consistent with the verified BooookScore and Wu et al. findings.
|
||||
|
||||
## добор: g1-cjk-sentence-primitives
|
||||
|
||||
- **[LB]** Unicode UAX #29 defines sentence boundaries with 。!? in the STerm class (ATerm holds only dot-like characters: U+002E, U+2024, U+FE52, U+FF0E), and rules SB9–SB11 keep closing quotes/brackets after a terminator attached to the sentence, so the break in 「…。」 falls AFTER the closing quote, not after 。.
|
||||
- Источник (standard): https://www.unicode.org/reports/tr29/#Sentence_Boundaries — UAX #29: Unicode Text Segmentation, Sentence Boundaries
|
||||
- Каветы: This is exactly the case naive 'split after 。!?' code gets wrong; a correct deterministic splitter must consume the Close* run (」』)” etc.) before emitting the boundary.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB]** UAX #29's default algorithm produces no sentence break at all when there is no terminal punctuation (fallback rule SB998 'Any × Any'), and the standard explicitly documents that plain text is inadequate for good boundaries (abbreviations, ellipsis, decimal periods), recommending tailored implementations.
|
||||
- Источник (standard): https://www.unicode.org/reports/tr29/#Sentence_Boundaries — UAX #29: Unicode Text Segmentation
|
||||
- Каветы: For webnovel lines that end without punctuation, the only deterministic boundary the standard gives you is the paragraph/line separator — the chunker must treat newline as a boundary of last resort by design, not hope the splitter finds one.
|
||||
- **VERDICT: OVERSTATED** — коррекция: Within a paragraph, UAX #29's default sentence-boundary rules produce no sentence break in the absence of sentence-terminating punctuation — the fallback rule SB998 "Any × Any" ("Otherwise, do not break") applies — though SB4 still breaks after paragraph separators (Sep | CR | LF). The standard explicitly states that "plain text provides inadequate information for determining good sentence boundaries," citing periods' ambiguity between end-of-sentence, abbreviations, and decimal points (ellipsis is not mentioned), and says implementations "can and should tailor" the default rules for particular locales or environments.
|
||||
- **[LB]** ICU's sentence BreakIterator implements the UAX #29 rules and offers abbreviation-suppression tailoring (locale tag ss=standard, ICU 64+) only for English, German, Spanish, French, Italian and Portuguese — there is no CJK-specific sentence tailoring, and ICU states more sophisticated linguistic analysis 'is not directly available from ICU at this time'.
|
||||
- Источник (official-doc): https://unicode-org.github.io/icu/userguide/boundaryanalysis/ — ICU User Guide: Boundary Analysis
|
||||
- Каветы: Means an ICU dependency buys you nothing over a faithful UAX #29 port for zh/ja; the CJK edge cases must be handled by your own tailoring layer either way.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB]** A pure-Go UAX #29 implementation with a sentence segmenter exists: github.com/clipperhouse/uax29 splits graphemes/words/sentences per Unicode 17 and is validated against the official Unicode test suites — a viable deterministic base layer without cgo/ICU bindings.
|
||||
- Источник (practitioner): https://github.com/clipperhouse/uax29 — clipperhouse/uax29: A tokenizer based on Unicode text segmentation (UAX #29), for Go
|
||||
- Каветы: Passing the Unicode conformance suite ≠ good behavior on webnovel text (emoji/kaomoji/no-punctuation lines are outside the suite); a tailoring layer on top is still required. The popular alternative neurosnap/sentences is a punkt port with no CJK support (https://github.com/neurosnap/sentences).
|
||||
- **[LB/M]** Measured Japanese benchmark (hkiyomaru/ja-senter-benchmark, micro-F1): rule-based splitters score 94.8–100 on Wikipedia and 83.7–88.4 on CC-100 web text, but 0.0 F1 on emoji-boundary and kaomoji test sets (pysbd, rhoknp, kuzukiri, hasami) and 44.4 on line-break cases; bunkai scores 100 on emoji and line breaks but 0 on named-entity periods (モーニング娘。); no tool wins everywhere.
|
||||
- Источник (practitioner): https://github.com/hkiyomaru/ja-senter-benchmark — ja-senter-benchmark: comparison of Japanese sentence segmentation tools
|
||||
- Каветы: Small test sets (15 Wikipedia docs, 15 CC-100 texts, hand-made edge-case sets annotated by the repo owner); authored by a researcher but not peer-reviewed. Directly relevant to webnovel style: the failure classes are exactly emoji/kaomoji/line-break cases.
|
||||
- **[ ]** Bunkai (Megagon Labs) is the documented reference design for Japanese UGC sentence splitting: a rule-based annotator pipeline handling emoji/emoticon terminators (♪★(笑)), plus an OPTIONAL ML component only for line-break disambiguation — i.e., the deterministic subset covers punctuation variety, and only 'is this newline a boundary?' was deemed to need a model (Hayashibe & Mitsuzawa, W-NUT 2020).
|
||||
- Источник (paper): https://github.com/megagonlabs/bunkai — megagonlabs/bunkai; paper: https://aclanthology.org/2020.wnut-1.10/ — Sentence Boundary Detection on Line Breaks in Japanese
|
||||
- Каветы: Paper PDF F1 numbers not extracted (parse failure); the ja-senter-benchmark row for bunkai serves as the measured proxy. For a chunker, treating ambiguous newlines conservatively (prefer NOT to end a sentence, but allow chunk break at paragraph marks) sidesteps the ML need.
|
||||
- **[ /M]** pragmatic_segmenter (rule-based, Ruby, the origin of the 'Golden Rules' test set) has dedicated rules for Japanese and Chinese; its Japanese golden rules keep text inside 「」 quotes unsplit (e.g. 「引き下げ幅は…」 stays one segment) and handle errant mid-sentence newlines; self-reported Golden Rules accuracy is 98.08% (English) and 100% (other languages), versus 31–66% for Stanford CoreNLP/OpenNLP/TactfulTokenizer.
|
||||
- Источник (practitioner): https://github.com/diasks2/pragmatic_segmenter — diasks2/pragmatic_segmenter
|
||||
- Каветы: Self-reported benchmark on the author's own test set (circular); the Golden Rules themselves are still the best available portable edge-case checklist for zh/ja/en, and ja_sentence_segmenter (https://github.com/wwwcojp/ja_sentence_segmenter) ports the JA subset to a split-then-reconcatenate pipeline (split_punctuation on 。!? + concatenate_matching for quotes/particles).
|
||||
- **[ ]** Portable SRX rule sets covering CJK exist and are inspectable: LanguageTool ships all-language rules in one segment.srx (Japanese break rule pattern reported as [\xff61\x3002\xff0e\xff1f\xff01]+ — halfwidth ideographic stop, 。, fullwidth .?!), and OmegaT ships defaultRules.srx with a Japanese rule breaking after 。 with empty after-context; SRX groups per-language break/exception regex rules with cascading.
|
||||
- Источник (official-doc): https://github.com/languagetool-org/languagetool/blob/master/languagetool-core/src/main/resources/org/languagetool/resource/segment.srx — LanguageTool segment.srx; https://github.com/omegat-org/omegat/blob/master/src/org/omegat/core/segmentation/defaultRules.srx — OmegaT defaultRules.srx; https://okapiframework.org/wiki/index.php?title=SRX — Okapi SRX
|
||||
- Каветы: The exact Japanese regex was surfaced via search snippets, not verified byte-for-byte against the raw file (file too large to fetch whole); verify against the repo before porting. Note SRX rules per CAT-tool convention break immediately after 。 — they do NOT implement UAX #29's Close* attachment, so raw SRX rules mis-handle 。」 unless an exception rule exists.
|
||||
- **[LB]** No Go implementation of SRX was found; the reference open implementations are Java (loomchild/segment, used by LanguageTool) and Rust (bminixhofer/srx, 'mostly compliant' SRX 2.0), and the standard itself specifies ICU regular expressions, which are documented as hard to reproduce exactly in other regex engines.
|
||||
- Источник (practitioner): https://github.com/bminixhofer/srx — bminixhofer/srx (Rust SRX 2.0); https://okapiframework.org/wiki/index.php?title=SRX — Okapi Framework: SRX
|
||||
- Каветы: Implication: consuming .srx files directly in Go means writing/porting an SRX engine and dealing with ICU-vs-RE2/regexp semantics (lookbehind is not in Go's regexp); hand-porting the small CJK rule set into native Go code is the lower-risk path.
|
||||
- **[LB/M]** For splitting oversized Chinese sentences, the comma is the documented clause-boundary device: Jin et al. (SIGHAN 2004) segment long Chinese sentences at classified commas with 87.1% comma-classification accuracy (improving parser accuracy by 9.6%), and Xue & Yang (ACL 2011) treat Chinese sentence segmentation as comma classification, since a subset of commas function as true end-of-sentence.
|
||||
- Источник (paper): https://aclanthology.org/W04-1101/ — Segmentation of Chinese Long Sentences Using Commas (Jin, Kim, Kim, Lee, SIGHAN 2004); https://aclanthology.org/P11-2111/ — Chinese sentence segmentation as comma classification (Xue & Yang, ACL 2011)
|
||||
- Каветы: Both use trained classifiers, not deterministic rules — 87% is the ceiling WITH ML; a deterministic 'any ,、;:' split is safe for token-budget purposes only if such cuts are marked soft/second-class (they are clause, not sentence, boundaries). Xue & Yang's EOS-comma F1 was reported around 70 via search snippet — not verified against the PDF. Related follow-up: Chinese Comma Disambiguation for Discourse Analysis (https://aclanthology.org/P12-1083.pdf).
|
||||
- **[LB/M]** DeepSeek officially publishes both a chars-per-token heuristic and an offline tokenizer: '1 English character ≈ 0.3 token, 1 Chinese character ≈ 0.6 token' (i.e., ≈3.3 en chars/token, ≈1.67 zh chars/token), with a downloadable deepseek_tokenizer.zip for computing exact usage locally without API calls, and an explicit caveat that the heuristic varies by model.
|
||||
- Источник (official-doc): https://api-docs.deepseek.com/quick_start/token_usage — DeepSeek API Docs: Token & Token Usage
|
||||
- Каветы: Independent measurement converges: DeepSeek R1 measured at 1.54 chars/token on C4 Chinese (see Medium tokenizer comparison), close to the official 1.67. No official ratio is published for Russian or Japanese — measure locally with the offline tokenizer. DeepSeek-V3 uses byte-level BPE, 128K vocab (https://arxiv.org/html/2412.19437v1 — DeepSeek-V3 Technical Report).
|
||||
- **[LB]** GLM-4's tokenizer is offline-computable in the same rank format tiktoken uses: the HF tokenization_chatglm.py imports tiktoken and loads base64-encoded mergeable ranks from a local tokenizer.model with a fixed pretokenizer regex (fully offline); per the GLM-4 report the vocabulary is 150K, byte-level BPE merged with cl100k_base tokens, with ~28K Chinese tokens.
|
||||
- Источник (official-doc): https://huggingface.co/THUDM/glm-4-9b/blob/main/tokenization_chatglm.py — THUDM/glm-4-9b tokenization_chatglm.py; https://arxiv.org/pdf/2406.12793 — ChatGLM: A Family of Large Language Models from GLM-130B to GLM-4 All Tools
|
||||
- Каветы: Because the format matches tiktoken's (base64 token + rank per line), Go tiktoken libraries with pluggable BPE loaders (e.g. pkoukk/tiktoken-go SetBpeLoader) can load GLM's vocabulary — exact GLM token counts in pure Go. Verify the newest GLM (glm-4.x/5 candidate) still ships the same tokenizer file before relying on it.
|
||||
- **[LB]** Pure-Go tiktoken implementations exist with embedded vocabularies (no runtime downloads): tiktoken-go/tokenizer embeds OpenAI vocabularies (~4MB) compiled into the binary and supports o200k_base and cl100k_base; pkoukk/tiktoken-go offers an offline BPE loader and pluggable loaders for custom rank files.
|
||||
- Источник (practitioner): https://github.com/tiktoken-go/tokenizer — tiktoken-go/tokenizer: Pure Go implementation of OpenAI's tiktoken; https://github.com/pkoukk/tiktoken-go — pkoukk/tiktoken-go
|
||||
- Каветы: Covers OpenAI-format tokenizers (GPT o200k/cl100k, and by format-compatibility GLM/DeepSeek rank files); it does NOT cover SentencePiece models (Gemini).
|
||||
- **[LB/M]** Gemini's official guidance is 'a token is equivalent to about 4 characters' for Gemini models, with exact counts available via the countTokens API; local (non-API) counting exists via SentencePiece-based tokenizers: Python vertexai.preview.tokenization and a Go package cloud.google.com/go/vertexai/genai/tokenizer that counts locally but downloads its tokenizer model from the web at runtime.
|
||||
- Источник (official-doc): https://ai.google.dev/gemini-api/docs/tokens — Understand and count tokens | Gemini API; https://pkg.go.dev/cloud.google.com/go/vertexai/genai/tokenizer — Go package tokenizer
|
||||
- Каветы: The '~4 chars/token' figure is English-centric and misleading for CJK/Cyrillic. The Go package's docs name only gemini-1.5-* examples; coverage of Gemini 2.x/3.x tokenizers is unverified — pin/vendor the downloaded model file for determinism, or budget Gemini by measured ratio plus margin. Gemini's tokenizer is SentencePiece (BPE/unigram) per Google docs and a Java port exists (https://glaforge.dev/posts/2024/10/04/a-gemini-and-gemma-tokenizer-in-java/).
|
||||
- **[ /M]** Measured on >2M translated sentence pairs under cl100k_base: Mandarin Chinese averages 1.76x the tokens of the English equivalent, Japanese 2.12x (with outlier sentences up to 8x), Korean 2.36x; rare hanzi can cost 2–3 tokens per character while common ones cost 1.
|
||||
- Источник (blog): https://tonybaloney.github.io/posts/cjk-chinese-japanese-korean-llm-ai-best-practices.html — Working with Chinese, Japanese, and Korean text in Generative AI pipelines (Anthony Shaw)
|
||||
- Каветы: Practitioner blog (Microsoft engineer), cl100k only — pre-o200k, so numbers are stale for GPT-4o-class models but remain the largest-corpus CJK measurement found. Also recommends splitting CJK on fullwidth 。.!? rather than ASCII '.'.
|
||||
- **[LB/M]** Measured six-task zh/ja corpus comparing OpenAI tokenizers: Chinese token-ratio vs English fell from 2.08x (cl100k_base) to 1.34x (o200k_base), Japanese from 2.32x to 1.73x; English runs ~5.4 chars/token vs Chinese 0.9–1.0 chars/token, and the authors warn vendor ratios cannot be inferred from tiktoken.
|
||||
- Источник (blog): https://masonailab.com/en/insights/token-efficiency/ — CJK Token Myth Busted — Measured Data | Mason AI Lab
|
||||
- Каветы: Small corpus (six task types, not a large-scale study); marketing-adjacent blog. Load-bearing because the safety-margin choice depends on this spread (chars/token for zh varies ~1.0 → ~1.7 across tokenizers, i.e. up to ~70% divergence if one table is applied to another vendor).
|
||||
- **[LB/M]** Same-text measurement (1,403-char Chinese article, translated variants): Gemini 3 Flash used 2,141 tokens for Japanese where DeepSeek V3.2 used 856 (2.5x), and 1,631 vs 636 for English; measured chars/token was 0.82–1.84 for Gemini vs 2.02–4.16 for DeepSeek — i.e., Gemini's SentencePiece (~256K vocab) is 2–2.8x less token-efficient per character than DeepSeek's BPE on this text.
|
||||
- Источник (blog): https://help.apiyi.com/en/gemini-vs-deepseek-tokenizer-efficiency-same-text-different-token-cost-guide-en.html — Gemini vs DeepSeek Tokenizer Efficiency Actual Test (Apiyi blog)
|
||||
- Каветы: Single test text, third-party API-reseller blog — treat as one datapoint, but it is the only found head-to-head of two tokenizers your pipeline actually uses; it forbids reusing one vendor's chars/token table for another (same conclusion as Mason AI Lab, independent voice).
|
||||
- **[ /M]** Russian tokenization is materially worse than English under GPT tokenizers but precise ratios are scarce: a Wikipedia-corpus cl100k study reports Russian costing 'more than double' English (chart-only, no table), and Petrov et al. (2023) measured cross-language tokenization length differences up to 15x across 17 tokenizers, establishing that per-language premiums are tokenizer-specific and large.
|
||||
- Источник (paper): https://tomaszurbanski.substack.com/p/the-hidden-price-tag-on-gpt-4-for — GPT-4's Hidden Cost: Is Your Language Pricing You Out (Substack); https://aleksandarpetrov.github.io/tokenization-fairness/ — Language Model Tokenizers Introduce Unfairness Between Languages (Petrov et al., 2023)
|
||||
- Каветы: No source provided an exact chars/token for Russian under DeepSeek/GLM/Gemini — and Russian is your OUTPUT language, so output-budget math needs a locally-measured number (trivial to obtain with the offline tokenizers above). A secondary blog claims 3–4 tokens per Cyrillic word under cl100k (unverified).
|
||||
- **[ ]** DeepSeek-V3's pretokenizer merges punctuation with line breaks into combined tokens (a compression optimization), which the technical report itself flags as introducing token-boundary bias around line-break-adjacent text — meaning chars/token near paragraph boundaries differs from mid-paragraph text.
|
||||
- Источник (paper): https://arxiv.org/html/2412.19437v1 — DeepSeek-V3 Technical Report
|
||||
- Каветы: Minor for budgeting (affects a few tokens per paragraph) but a concrete reason why chars-per-token heuristics drift with text shape (dialogue-heavy webnovel text has many short lines); exact offline tokenization absorbs this automatically.
|
||||
|
||||
## добор: g2-diff-editor-contract
|
||||
|
||||
- **[LB/M]** In the WMT 2019 APE shared task English-Russian round, NO submitted system improved over the do-nothing baseline (leaving the strong NMT output untouched, 16.16 TER / 76.20 BLEU); every APE run degraded or failed to beat it.
|
||||
- Источник (paper): https://aclanthology.org/W19-5402/ — Findings of the WMT 2019 Shared Task on Automatic Post-Editing (Chatterjee et al.)
|
||||
- Каветы: Pre-LLM APE systems (2019, transformer-era) on news domain; only 2 teams / 4 runs on en-ru. Still the single most direct evidence that on a strong draft into Russian, an unconstrained post-editor's expected value is negative — the editor contract needs an explicit, cheap do-nothing path and must be benchmarked against do-nothing.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** WMT APE gains collapse as base-MT quality rises: PBSMT-era drafts allowed up to -6.24 TER / +9.53 BLEU improvement (WMT 2018), but on NMT drafts the best 2019 en-de system managed only -0.78 TER / +1.23 BLEU, and organizers attribute the difficulty to over-correction of already-adequate output.
|
||||
- Источник (paper): https://www.aclweb.org/anthology/W18-6452 and https://aclanthology.org/W19-5402/ — Findings of the WMT 2018/2019 Shared Tasks on Automatic Post-Editing
|
||||
- Каветы: The WMT findings series (2018-2023) is one organizer voice across years, though datasets differ. Numbers are corpus-level TER/BLEU, not a per-sentence 'X% of adequate sentences degraded' rate — that finer statistic was not extractable from abstracts fetched. Later rounds (2020 en-de: -11.35 TER; en-zh: -12.13 TER) used deliberately lower-quality drafts, so large gains there do not contradict the trend.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[ /M]** Over-correction is an explicitly named, still-open APE failure mode in 2025: unnecessary modifications violating minimal-editing; injecting word-level QE 'OK/BAD' tags as decoding constraints (preserve OK tokens) improves APE by 0.65 TER (en-de), 1.86 (en-hi), 1.44 (en-mr) over unconstrained APE.
|
||||
- Источник (paper): https://arxiv.org/abs/2501.17265 — Giving the Old a Fresh Spin: Quality Estimation-Assisted Constrained Decoding for Automatic Post-Editing (NAACL 2025)
|
||||
- Каветы: Token-level constrained decoding is not directly available through commercial chat APIs; the transferable idea is gating which spans the editor may touch. No Russian pair tested.
|
||||
- **[LB/M]** GPT-4 as a translation post-editor (WMT-22 test sets) improved COMET-22 on all pairs tested (e.g., zh-en 80.35→82.79, en-zh 86.69→87.53, en-de 86.78→87.37), and a chain-of-thought 'propose edits, then apply' format cut edit magnitude by roughly a third (TER between draft and post-edit: en-zh 94.5→70.3, zh-en 34.9→22.0) while keeping the quality gain; authors still document hallucinated edits and urge caution.
|
||||
- Источник (paper): https://arxiv.org/abs/2305.14878 — Leveraging GPT-4 for Automatic Translation Post-Editing (Raunak et al., EMNLP 2023 Findings)
|
||||
- Каветы: 2023, GPT-4 (frontier tier), sentence-level news/general domain, no Russian target, reference-based metrics. Key transferable result: an enumerate-edits-first output contract measurably reduces how much of the draft gets rewritten without losing the quality gain — direct support for the narrow-mandate design, but at frontier model class.
|
||||
- **VERDICT: OVERSTATED** — коррекция: GPT-4 post-editing of MS-Translator outputs on WMT-22 test sets improved COMET-22 on the four main pairs tested (zh-en 80.35→82.79, en-zh 86.11→87.53, en-de 86.78→87.37, de-en 84.68→85.41), with direct post-editing also surpassing the WMT-Best systems (e.g., en-zh WMT-Best 86.69); of twelve additional pairs tested in the CoT setting, most improved but En-Cs, En-Is, and Is-En declined. The chain-of-thought 'propose edits, then apply' format made edits substantially more conservative (TER between draft and post-edit: en-zh 94.5→70.3, zh-en 34.9→22.0, i.e., roughly a quarter to a third less editing), still improving over the initial translations though with a smaller quality gain than direct post-editing; the authors document hallucinated edits and urge caution.
|
||||
- **[ /M]** LLMs doing prose correction over-edit measurably: on CoNLL-14 GEC, ChatGPT (3-shot CoT) scored precision 51.3 vs GECToR 75.6 and T5-large 72.2 (F0.5 53.2 vs 66.3/66.8), and human evaluation rated it highest in over-correction among all compared systems; it ignores minimal-edit instructions most on short sentences.
|
||||
- Источник (paper): https://arxiv.org/abs/2304.01746 — Is ChatGPT a Highly Fluent Grammatical Error Correction System? A Comprehensive Evaluation (2023)
|
||||
- Каветы: GEC on English learner text, GPT-3.5-era ChatGPT; precision penalty partially reflects reference bias of minimal-edit benchmarks (fluent rewrites scored as errors). Direction (LLM default = fluency rewrite, not minimal edit) is corroborated independently by the minimal-edit GEC line (arXiv 2506.13148) and edit-level majority-voting work.
|
||||
- **[ ]** Mitigations for LLM over-correction exist as a 2025-2026 research line: sampling multiple candidate corrections and keeping only edits that win an edit-level majority vote (arXiv 2605.13624, nine benchmarks, seven languages incl. Czech/Ukrainian/German), and error-rate-adapted training schedules for minimal-edit GEC (arXiv 2506.13148, SOTA single-model BEA-test).
|
||||
- Источник (paper): https://arxiv.org/pdf/2605.13624 and https://arxiv.org/abs/2506.13148
|
||||
- Каветы: Both are benchmark-backed papers but I could not extract their exact deltas from the abstracts fetched — treat magnitudes as unverified; the existence and mechanism (vote at the level of individual edits, not whole outputs — only possible if the editor emits discrete edits) is what matters for the design.
|
||||
- **[LB/M]** Aider's refactor benchmark (89 large Python refactor tasks): GPT-4 Turbo scored 20% with search/replace blocks vs 61% with unified diff, and lazy placeholder-comment tasks dropped 12→4; GPT-4-0613 similarly 26%→59%.
|
||||
- Источник (practitioner): https://aider.chat/docs/unified-diffs.html — Unified diffs make GPT-4 Turbo 3X less lazy (aider, Dec 2023)
|
||||
- Каветы: One practitioner voice (aider/Paul Gauthier) — all aider numbers in this report share that origin. Task = long code refactors where the failure mode is truncation/laziness, not fidelity; result is specific to GPT-4 Turbo 2023 and does NOT generalize to weaker models (see GPT-3.5 finding) nor to prose. Later aider defaults moved most models to search/replace ('diff') format.
|
||||
- **[LB/M]** Apply-side tolerance dominates end-to-end edit reliability: in aider's ablations, disabling flexible (fuzzy, context-anchored) patch application caused a 9X increase in editing errors, and dropping 'high level diff' prompting (encouraging whole-block replacement over minimal ± lines) added 30-50% more errors; aider also explicitly avoids line numbers in diffs.
|
||||
- Источник (practitioner): https://aider.chat/docs/unified-diffs.html — aider unified-diffs writeup
|
||||
- Каветы: Same single aider origin; code domain. Directly transferable: the deterministic Go applier should locate edit anchors tolerantly (whitespace/normalization-insensitive search, nearby-context matching) rather than requiring byte-exact patches, and the format should ask for coherent replaced spans, not line-number-addressed minimal diffs.
|
||||
- **[LB/M]** Weak/cheap models cannot emit edit formats reliably and do better returning the whole text: GPT-3.5-turbo scored 46% (whole-file) vs 30% (search/replace diff) on aider's original benchmark, with pathological behavior like putting the entire file in the ORIGINAL block; aider therefore assigns 'whole' format to weak models permanently.
|
||||
- Источник (practitioner): https://aider.chat/docs/benchmarks.html — GPT code editing benchmarks (aider, 2023)
|
||||
- Каветы: Same aider origin; 2023 models. Defines the capability floor: the narrow-mandate contract presumes the editor model clears a format-emission threshold — must be verified per candidate model, not assumed.
|
||||
- **[LB/M]** Current mid-tier models clear that threshold on aider's polyglot leaderboard 'percent using correct edit format': DeepSeek-V3.2 chat 98.2% (diff), Gemini 2.5 Flash 95.6% (diff), Qwen3-235B 92.9% (diff), Claude 3.5 Haiku 91.1% (diff); frontier models reach 97-100%; GPT-4o-mini is still run in whole-file mode.
|
||||
- Источник (practitioner): https://aider.chat/docs/leaderboards/ — Aider polyglot leaderboard
|
||||
- Каветы: Same aider origin; aider's 'diff' is fenced SEARCH/REPLACE blocks, not unified diff; compliance is measured on code with retry loops available; a 2-9% malformed-edit rate at mid-tier means the pipeline needs a validate-and-retry (or reject-edit) path. GPT-4o-mini's 100% is trivial — whole-file format has almost nothing to get wrong.
|
||||
- **[LB/M]** Diff-XYZ (JetBrains, arXiv Oct 2025; 1,000 real commits): for the model-GENERATES-the-diff task, search/replace is by far the most reliably emitted format (exact-match: GPT-4.1 0.95, Claude 4 Sonnet 0.94, Qwen 32B 0.68) vs unified diff (0.77 / 0.82 / 0.23); for the model-APPLIES-the-diff task the ranking flips (udiff apply EM: Claude 4 Sonnet 0.95, GPT-4.1 0.90, Qwen 7B 0.58, Qwen 3B 0.36, while search-replace apply plateaus ~0.57); verbose tagged udiff-l is best for the smallest models, and formatting choice barely helps models <7B.
|
||||
- Источник (paper): https://arxiv.org/abs/2510.12487 — Diff-XYZ: A Benchmark for Evaluating Diff Understanding (JetBrains Research, 2025)
|
||||
- Каветы: Code only (Python/JS/Java/Kotlin/Rust), single paper. Crucial reading for this pipeline: our applier is deterministic Go, so only the GENERATION numbers bind — and they favor search/replace emission at every tested size; the poor search-replace APPLY score reflects LLM-as-applier ambiguity, which a deterministic exact/fuzzy matcher avoids. The flat 0.57 apply score across models is suspicious (likely a format-ambiguity ceiling) and unexplained in what I extracted.
|
||||
- **[ /M]** Copy-as-Decode (arXiv 2604.18170, Apr 2026) shows grammar-constrained span-edit output (<copy lines=i-j/> + <gen>) is mechanically lossless — 482/482 oracle cases round-trip byte-exactly, including a prose dataset (ProbeEdit: meeting notes, design doc, scientific abstract) — but SPAN SELECTION is the hard part for small models: a trained Qwen2.5-1.5B selector reached only 12-17% held-out exact match; copying via parallel prefill is 6.8-303x faster than regenerating tokens.
|
||||
- Источник (paper): https://arxiv.org/abs/2604.18170 — Copy-as-Decode: Grammar-Constrained Parallel Prefill for LLM Editing (2026)
|
||||
- Каветы: Very recent preprint, tiny datasets (154 prose cases), mechanism-level study, selector results explicitly below deployment threshold. It is the only source found that evaluates structured span-edits on prose at all, and it says deciding WHERE to edit, not encoding the edit, is the bottleneck for small models.
|
||||
- **[ /M]** Cascaded editing — a strong model emits a concise edit sketch, a fine-tuned 14B model materializes it — beats the strong model editing directly: +11.1% Pass@2 over DeepSeek R1 alone on the Aider benchmark, with 13% less time and 19% less cost (FSE 2026).
|
||||
- Источник (paper): https://arxiv.org/abs/2604.19201 — Cascaded Code Editing: Large-Small Model Collaboration (FSE 2026)
|
||||
- Каветы: Code editing, single recent paper, requires a fine-tuned applier model. Supports the general pattern of separating edit-decision from edit-serialization, which the translator→editor pipeline mirrors (editor decides, Go code applies).
|
||||
- **[ ]** Both major vendors publish an official trained edit format and both avoid line numbers: OpenAI's GPT-4.1 guide open-sources the V4A apply_patch diff (context-anchored, 'no need for line numbers', model 'extensively trained' on it); Anthropic's official file-editing tool is str_replace-based (exact-match search/replace of a unique old string).
|
||||
- Источник (official-doc): https://developers.openai.com/cookbook/examples/gpt4-1_prompting_guide (OpenAI GPT-4.1 Prompting Guide) and https://platform.claude.com/docs/en/agents-and-tools/tool-use/text-editor-tool (Anthropic text editor tool docs)
|
||||
- Каветы: Vendor guidance, no published numbers; but it means frontier and mid-tier commercial models are RL-trained on context-anchored search/replace-style edits, so a search/replace contract rides with the training distribution while a bespoke format fights it.
|
||||
- **[LB/M]** The closest published analogue to the narrow-mandate translation editor: guiding LLaMA-2 7B/13B to post-edit MT with external MQM error-span annotations (zh-en, en-de, en-ru) improves TER/BLEU/COMET; fine-grained span feedback beats generic 'improve this' feedback only after fine-tuning (4-6 BLEU gap); when fed 200 already-correct translations the models still edited them, causing a small automatic-metric drop.
|
||||
- Источник (paper): https://aclanthology.org/2024.findings-naacl.265/ (arXiv 2404.07851) — Guiding Large Language Models to Post-Edit Machine Translation with Error Annotations (Ki & Carpuat, NAACL 2024 Findings)
|
||||
- Каветы: Sentence-level news MT, small open models, en-ru is INTO Russian only as one of three pairs; 'small drop on correct inputs' shows even span-guided editors do not fully abstain — an external do-nothing gate is still needed. No comparison of span-REPLACEMENT output vs free rewrite output was run; the model still regenerated full sentences.
|
||||
- **[ ]** Flag-only editing exists in evaluator form and is measurable: MQM-APE improves LLM error-span annotation quality by testing each flagged error via a post-edit and keeping only quality-improving edits, working consistently across eight LLMs including low-resource languages — i.e., an edit-verification loop can filter non-impactful edits without retraining.
|
||||
- Источник (paper): https://arxiv.org/abs/2409.14335 — MQM-APE: Toward High-Quality Error Annotation Predictors with Automatic Post-Editing in LLM Translation Evaluators (2024)
|
||||
- Каветы: Aimed at evaluation (error annotation quality), not final translation quality; exact deltas not extracted from the fetched material. Demonstrates a per-edit accept/reject verifier pattern that maps directly onto a judge-gated narrow editor.
|
||||
|
||||
## добор: g3-experiment-methodology
|
||||
|
||||
- **[LB/M]** Miller (Anthropic) gives five concrete recommendations for LLM eval statistics: compute SEs via CLT, use clustered standard errors when questions are drawn in related groups, reduce variance by resampling (K generations per question), conduct inference on question-level PAIRED differences rather than aggregate scores, and run power analysis to size the eval. The paired-difference SE is SE_paired = sqrt(SE_A^2 + SE_B^2 - 2*SE_A*SE_B*Corr(s_A,s_B)).
|
||||
- Источник (paper): https://arxiv.org/abs/2411.00640 — 'Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations' (Miller, 2024)
|
||||
- Каветы: Framework paper with worked benchmark examples; developed for question-level benchmarks (MMLU-style), not generation quality — but the estimators are generic. Our 'question' = chapter, 'cluster' = book.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Ignoring clustering understates uncertainty by large factors in real evals: in Miller's Table 4, clustered vs naive SE ratios are 3.05x on DROP (questions nested in passages), 1.88x on MGSM, 1.10x on RACE-H. For chapters nested in books, book-level clustering of SEs is therefore mandatory, not optional.
|
||||
- Источник (paper): https://arxiv.org/abs/2411.00640 — 'Adding Error Bars to Evals' (Miller, 2024), Table 4
|
||||
- Каветы: Cluster inflation is dataset-specific; the chapter-in-book ICC for translation cohesion scores is unknown and must be estimated from a pilot.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Miller's power formula for a paired two-model comparison is n = (z_{alpha/2}+z_beta)^2 * (omega^2 + sigma_A^2/K_A + sigma_B^2/K_B) / delta^2, where omega^2 = Var(x_A)+Var(x_B)-2Cov(x_A,x_B) and K is resamples per question. Worked example: detecting a 3% absolute difference at 80% power / alpha=0.05 requires ~969 questions; with n=198 fixed, raising K from 1 to 10 shrinks the minimum detectable effect from 13.2% to 7.5%.
|
||||
- Источник (paper): https://arxiv.org/abs/2411.00640 — 'Adding Error Bars to Evals' (Miller, 2024), power analysis section
|
||||
- Каветы: The 969-question example assumes the paper's illustrative variance parameters; plug in pilot-estimated omega^2 for chapter-level cohesion scores. Numbers are per unclustered question — apply the design effect on top for book clustering.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB/M]** Wang (FAIR, 'Measuring all the noises of LLM Evals') decomposes eval noise into prediction noise (sampling variability per question) and data noise (question sampling) via the law of total variance, measured over millions of question-level predictions. Paired prediction noise typically exceeds paired data noise, so averaging repeated generations per question detects effect sizes ~2x smaller for unrelated models and 6x+ smaller for related models (e.g., two variants of the same pipeline).
|
||||
- Источник (paper): https://arxiv.org/abs/2512.21326 — 'Measuring all the noises of LLM Evals' (Sida Wang, Dec 2025; interactive results at all-the-noises.github.io)
|
||||
- Каветы: Single author / single origin; measured on standard capability benchmarks (code, QA), not translation-quality judging. But arms sharing a base pipeline are exactly the 'related models' regime, so K>1 generations/judgments per chapter is a cheap power multiplier.
|
||||
- **[LB/M]** Resolution Diagnostics (Kotawala, May 2026) gives the paired sample-size formula N* = ((z_{1-alpha/2}+z_{1-beta}) * sigma_D / |delta|)^2 with sigma_D^2 = pA*qA + pB*qB - 2*rho*sqrt(pA*qA*pB*qB), a resolution ratio q = N/N* (resolvable iff q>=1), and a clustering design effect DE = 1 + (m_bar - 1)*ICC(D) that scales N*. At alpha=0.05/power 0.8 with typical benchmark parameters (p~0.65, rho~0.3), resolving 1–2 percentage-point gaps requires N in the thousands to tens of thousands.
|
||||
- Источник (paper): https://arxiv.org/html/2605.30315v1 — 'Resolution Diagnostics for Paired LLM Evaluation' (arXiv 2605.30315)
|
||||
- Каветы: Formulas are for binary outcomes; for continuous 0-5 quality scores use sigma_D of paired score differences directly. Recent preprint, apparently single-author, not yet peer-reviewed. Clustering example uses MMLU-Pro subject categories (raised unresolved pairs from 4/9 to 6/9).
|
||||
- **[ /M]** The common shortcut of taking an unpaired Cohen-h sample size and post-multiplying by (1-rho) underestimates required N by roughly a factor of two in the close-comparison regime; three of five standard calculators (Cohen 1988 textbook, G*Power 3.1, R pwr) silently inherit this error. Do not size the paired chapter experiment with an unpaired calculator plus a correlation discount.
|
||||
- Источник (paper): https://arxiv.org/html/2605.30315v1 — 'Resolution Diagnostics for Paired LLM Evaluation' (arXiv 2605.30315)
|
||||
- Каветы: Affects the prereg's power calculation procedure, not the pipeline itself. Proven as a lemma for binary metrics near p=0.5.
|
||||
- **[ /M]** Card et al. (EMNLP 2020) meta-analysis found underpowered experiments are common in NLP; for machine translation, a typical 2000-sentence test set has only ~75% power to detect a 1-BLEU-point difference. They release notebooks for NLP power analysis.
|
||||
- Источник (paper): https://aclanthology.org/2020.emnlp-main.745/ — 'With Little Power Comes Great Responsibility' (Card, Henderson, Khandelwal, Jia, Mahowald, Jurafsky, EMNLP 2020); code: https://github.com/dallascard/NLP-power-analysis
|
||||
- Каветы: NMT-era, sentence-level BLEU; magnitudes don't transfer to chapter-level human/LLM cohesion scores, but the qualitative lesson (typical NLP eval sizes only resolve moderate deltas) does.
|
||||
- **[ ]** For multi-arm / multi-dataset comparisons, Dror et al. (TACL 2017) provide a replicability-analysis framework based on partial conjunction testing with Bonferroni and Fisher variants (for independent vs dependent datasets), shown to be more powerful than plain Bonferroni while keeping conclusions statistically valid — a citable multiple-comparison procedure for a prereg with several arms and two endpoints.
|
||||
- Источник (paper): https://arxiv.org/abs/1709.09500 — 'Replicability Analysis for Natural Language Processing: Testing Significance with Multiple Datasets' (Dror, Baumer, Bogomolov, Reichart, TACL 2017)
|
||||
- Каветы: Methodological paper; designed for multiple datasets rather than multiple arms — for a small number of pre-registered arm contrasts, Holm-Bonferroni on the primary endpoint family is the simpler defensible choice.
|
||||
- **[LB/M]** Zheng et al. (NeurIPS 2023, MT-Bench/Chatbot Arena) established that a strong LLM judge (GPT-4) reaches over 80% agreement with human preferences on pairwise chat comparisons — the same level as human-human agreement — while documenting position bias, verbosity bias, and self-enhancement bias as systematic judge failure modes that need explicit control.
|
||||
- Источник (paper): https://arxiv.org/abs/2306.05685 — 'Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena' (Zheng et al., NeurIPS 2023)
|
||||
- Каветы: Single origin paper that most later judge-agreement claims re-cite — treat the '80%' as one voice. Measured on short chat responses in 2023, NOT on document-level translation cohesion; agreement on long-form cohesion must be re-measured against the human reader in-experiment.
|
||||
- **[LB/M]** Wang et al. 2023 measured that position bias alone can flip pairwise verdicts wholesale: by merely reordering candidates, Vicuna-13B could be made to 'beat' ChatGPT on 66 of 80 queries. Their mitigation, Balanced Position Calibration, evaluates each pair in both orders and aggregates — i.e., a minimum of 2 judge calls per pair with order swap is the floor for any pairwise protocol.
|
||||
- Источник (paper): https://arxiv.org/abs/2305.17926 — 'Large Language Models are not Fair Evaluators' (Wang et al., 2023)
|
||||
- Каветы: Measured with 2023 judges (GPT-3.5/GPT-4 era) on short outputs; bias magnitude on 2026 judges over chapter-length texts may differ but the swap-test control is standard regardless.
|
||||
- **[LB/M]** A 2026 reliability study ('The Coin Flip Judge?', GPT-4o-mini and GPT-4.1-mini judges, 29 tasks) measured a mean pairwise verdict flip rate of 13.6% across repeated calls (28% of questions exceed 20% flip rate), dropping to 2.8–7.9% at temperature=0. It recommends >=10–11 repeated trials with majority voting and randomized position to recover the 50-trial reference verdict with 95% probability; high-variance items need 15+ trials.
|
||||
- Источник (paper): https://arxiv.org/abs/2606.13685 — 'The Coin Flip Judge? Reliability and Bias in LLM-as-a-Judge Evaluation' (arXiv 2606.13685, 2026)
|
||||
- Каветы: Recent preprint, small judge models, general short-form tasks — the 10-trial number is a starting point, not gospel for chapter-length cohesion judging; per-pair trial count trades directly against the cost endpoint. Alternative supported by the noises paper: fewer trials per pair but more pairs.
|
||||
- **[LB/M]** WMT24 Discourse-Level Literary Translation task is the closest published protocol to chapter-level webnovel judging: test sets of 12 books / 239 chapters (Zh-En, 337K words) and 122 chapters (Zh-Ru); human evaluation by 3 professional evaluators on a 0–5 scale along two dimensions — General Quality (fluency/adequacy) and Discourse Awareness (consistency, word choice, anaphora) — reaching 0.86 Cohen's kappa on Zh-En; automatic metric was document-level sacreBLEU (d-BLEU) over concatenated chapters.
|
||||
- Источник (paper): https://arxiv.org/abs/2412.11732 — 'Findings of the WMT 2024 Shared Task on Discourse-Level Literary Translation' (also https://aclanthology.org/2024.wmt-1.58/)
|
||||
- Каветы: Human eval ran only on Zh-En (too few Zh-De/Zh-Ru submissions) — there is no published human chapter-level protocol validated for Zh-Ru specifically. Evaluators were professionals scoring absolute 0-5 per dimension, not pairwise preference.
|
||||
- **[LB/M]** The same WMT24 literary findings report a significant gap between human and automatic rankings for at least one system (NTU scored lowest in human eval, 2.58 general / 2.42 discourse, while looking acceptable on automatic metrics) — document-level BLEU-family metrics cannot be the sole cohesion endpoint.
|
||||
- Источник (paper): https://arxiv.org/abs/2412.11732 — 'Findings of the WMT 2024 Shared Task on Discourse-Level Literary Translation'
|
||||
- Каветы: One task edition, Zh-En only; still the direct precedent for keeping the human reader as primary judge of cohesion with LLM judges as secondary.
|
||||
- **[ /M]** ESA (Error Span Annotation, Kocmi et al. 2024) — continuous DA-style rating combined with error-severity span marking — delivers annotations 'faster and cheaper than MQM at the same quality level' without requiring MQM experts, and WMT24's general task used document-level human evaluation for official rankings; ESA is a citable middle-weight protocol for the human reader's chapter assessments.
|
||||
- Источник (paper): https://arxiv.org/abs/2406.11580 — 'Error Span Annotation: A Balanced Approach for Human Evaluation of Machine Translation' (Kocmi et al., 2024); WMT24 metrics task context: https://www2.statmt.org/wmt24/metrics-task.html
|
||||
- Каветы: Validated on En-De WMT23 system outputs at segment/document granularity, not on literary chapter cohesion; adopt the 0-5 two-dimension literary protocol as primary and ESA-style span marking as optional enrichment.
|
||||
- **[ /M]** DITING/AgentEval (2025) is a published evaluation framework specifically for web-novel translation, scoring six dimensions including terminology localization, tense consistency, and zero-pronoun resolution via multi-agent LLM deliberation; it achieved the highest correlation with human judgments among seven tested automatic metrics, backed by 18K+ expert-annotated Zh-En pairs and a 300-pair meta-evaluation set (MetricAlign).
|
||||
- Источник (paper): https://arxiv.org/abs/2510.09116 — 'DITING: A Multi-Agent Evaluation Framework for Benchmarking Web Novel Translation' (2025)
|
||||
- Каветы: Sentence-pair granularity, Zh-En only — evidence that LLM judging of webnovel-specific phenomena is viable, not a chapter-level cohesion protocol; exact correlation coefficients not extracted from the abstract.
|
||||
- **[ ]** van Miltenburg, van der Lee & Krahmer (NAACL 2021) is the standard citation for NLP pre-registration; its appendix provides question templates per study type including 'NLP engineering experiment' (hypotheses, data, evaluation metrics specified in advance), and argues for registered reports. A counterpoint discussion exists (Søgaard et al., EACL 2023).
|
||||
- Источник (paper): https://aclanthology.org/2021.naacl-main.51/ — 'Preregistering NLP research' (van Miltenburg et al., NAACL 2021); counterpoint: https://aclanthology.org/2023.eacl-main.6.pdf — 'A Two-Sided Discussion of Preregistration of NLP Research' (EACL 2023)
|
||||
- Каветы: Templates are generic per study type; no published OSF prereg example was found for a multi-arm LLM-pipeline experiment with cost and quality co-primary endpoints — ours would need to compose the NLP template with the OSF standard template.
|
||||
- **[ ]** The OSF preregistration template explicitly requires the elements the experiment needs to freeze: sample size and its rationale ('including all power calculations'), a stopping rule ('if... not full control over your exact sample size, specify how you will decide when to terminate'; sequential-analysis thresholds must be pre-specified), and a single pre-specified statistical method per hypothesis to preclude method-shopping.
|
||||
- Источник (official-doc): https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.3000937 — 'Ensuring the quality and specificity of preregistrations' (PLOS Biology, 2020; describes OSF template fields); template mirror: https://gist.github.com/JoKeyser/3506f3087bc68dda89f32f56ed9c283c
|
||||
- Каветы: OSF template originates in psychology; stopping-rule language transfers directly (e.g., 'stop after N pre-registered chapter pairs or budget X, whichever first').
|
||||
- **[LB/M]** Cost-of-Pass (arXiv 2504.13359, 2025) is the citable retry-adjusted cost framework: v(m,p) = C_m(p) / R_m(p), the expected cost per attempt divided by per-attempt success probability — under independent retries the expected number of attempts to first success is geometric, 1/R_m(p), so v is the expected monetary cost of one accepted output. Frontier cost-of-pass V_p = min over available models (optionally including a human-expert cost baseline); inference-time techniques (majority voting, self-refinement) enter through inflated C_m(p) and 'rarely justify the costs'.
|
||||
- Источник (paper): https://arxiv.org/abs/2504.13359 — 'Cost-of-Pass: An Economic Framework for Evaluating Language Models' (2025)
|
||||
- Каветы: Assumes binary pass/fail and independent identically-distributed retries; a translation pipeline with graded acceptance and partial retries (re-run only failed chunks/gates) needs a stated extension: cost-per-accepted-chapter = sum of all attempt costs (including judge/gate calls) divided by number of accepted chapters, with the acceptance criterion pre-registered.
|
||||
- **[ /M]** A 2025 LLM-as-judge deployment study operationalizes first-attempt reliability as ECR@1 (Evaluation Completion Rate), measuring 85.4%–100% across judge models 'with material cost implications via retries' — precedent for reporting per-arm retry rates alongside the cost endpoint rather than folding them silently into averages.
|
||||
- Источник (paper): https://arxiv.org/abs/2512.01232 — 'LLM-as-a-Judge for Scalable Test Coverage Evaluation: Accuracy, Operational Reliability, and Cost' (2025)
|
||||
- Каветы: Domain is test-coverage judging, not translation; exact retry-to-cost formula not extractable from the abstract. Practitioner/industry blogs echo 'cost per successful task' but add no formal framework beyond Cost-of-Pass.
|
||||
|
||||
## добор: g4-russian-target-norms
|
||||
|
||||
- **[LB]** Russian fiction dialogue norm (Розенталь, Пунктуация, раздел 14, § 52): each reply given from a new paragraph is introduced by an em-dash (тире) WITHOUT quotation marks; quotes + dash separators are used only when replies run in-line without attribution; if author's words follow a reply, the тире before the next reply is dropped.
|
||||
- Источник (standard): http://old-rozental.ru/punctuatio.php?sid=160 — Розенталь, «Знаки препинания при диалоге» (§ 52)
|
||||
- Каветы: old-rozental.ru is an online reproduction of the handbook, not a scan of a specific edition; § numbering matches the widely used «Справочник по русскому языку. Пунктуация».
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB]** Розенталь § 47: in-line direct speech is enclosed in кавычки; direct speech starting a new paragraph is introduced by тире; internal (unspoken) thoughts are ALWAYS in кавычки regardless of position — so a sanitizer must distinguish speech vs thought before choosing dash vs quotes.
|
||||
- Источник (standard): http://old-rozental.ru/punctuatio.php?sid=155 — Розенталь § 47 «Оформление прямой речи»
|
||||
- Каветы: Online reproduction; thought-vs-speech distinction cannot be decided by regex alone — it needs upstream annotation from the translation stage.
|
||||
- **VERDICT: CONFIRMED**
|
||||
- **[LB]** Розенталь § 48: direct speech after author's words takes a colon and initial capital; the colon is licensed only when the attribution contains a speech/thought verb (сказал, спросил…) — otherwise no colon; ?/!/… go before closing quotes, the period after them.
|
||||
- Источник (standard): http://old-rozental.ru/punctuatio.php?sid=156 — Розенталь § 48 «Прямая речь после слов автора»
|
||||
- **VERDICT: OVERSTATED** — коррекция: Розенталь § 48: direct speech after author's words takes a colon and initial capital; ?/!/… go before closing quotes, the period after them. The colon is licensed not only by speech/thought verbs (сказал, спросил, подумал…) but also by nouns close in meaning (вопрос, ответ, слова, восклицание, крик, мысль) and by verbs of feeling/action that admit an added speech verb (обрадовался, удивился, улыбнулся, подбежал); the colon is omitted only when inserting «и сказал / и спросил / и воскликнул» is impossible or awkward.
|
||||
- **[LB]** Розенталь § 49: direct speech BEFORE author's words ends in comma (or ?/!/…) plus тире, never a period, and the attribution starts lowercase — a deterministic lint: «. —» followed by lowercase attribution verb is always wrong; «, —» with capitalized attribution is also wrong.
|
||||
- Источник (standard): http://old-rozental.ru/punctuatio.php?sid=157 — Розенталь § 49 «Прямая речь перед словами автора»
|
||||
- **[LB]** Розенталь § 50: author's words INSIDE a reply follow five closed patterns — «, — …, —» (lowercase continuation), «, — …. —» (capitalized), «? — …. —» / «! — …. —», «… — », and «: —» when the attribution has two speech verbs; quotes are never re-opened around the attribution.
|
||||
- Источник (standard): http://old-rozental.ru/punctuatio.php?sid=158 — Розенталь § 50 «Слова автора внутри прямой речи»
|
||||
- Каветы: The five sub-cases determine capitalization of the continuation — a checker must know whether the original sentence would have ended at the break point, which is not purely lexical.
|
||||
- **[LB]** Полный академический справочник под ред. Лопатина §§ 154–157: in «?!» the question mark always precedes; when ? or ! combines with ellipsis the mark stands in place of the FIRST dot (yielding exactly «?..» and «!..», never «?...»); a comma meeting an ellipsis is absorbed by it; the legal direct-speech sequences are «запятая, тире», «?/! , тире», «точка, тире», «многоточие, тире», «двоеточие, тире».
|
||||
- Источник (standard): http://orthographia.ru/punctuatio.php?sid=143 — «Сочетание знаков препинания…», Полный академический справочник (ред. В. В. Лопатин), §§ 154–157
|
||||
- Каветы: orthographia.ru reproduces the 2006 academic handbook; gramota.ru teaches the same rule (https://gramota.ru/uchebnik/pravila/sochetanie-znakov-prepinaniya). These are fully regexable sanitizer rules.
|
||||
- **[ ]** Publishing practice per Мильчин & Чельцова «Справочник издателя и автора» (3-е изд., 2009): first-level quotes in Cyrillic editions are ёлочки « », nested quotes are лапки „ “, third level single лапки — a normalization rule for quotes-within-quotes and for converting CJK 「」『』 or English “ ” quotes.
|
||||
- Источник (practitioner): https://habr.com/ru/articles/707186/ — «Кавычки при вложенных цитатах» (Habr, cites Мильчин 2009); corroborated by https://gramota.ru/biblioteka/spravochniki/pismovnik/v-chem-raznitsa-mezhdu-kavychkami-raznogo-risunka
|
||||
- Каветы: Primary text unavailable online except as image-scan PDFs (e.g., editors.tsu.ru, apsolyamov.ru — OCR failed), so exact Мильчин section numbers for dialogue layout could not be verified; dialogue-layout provisions are anyway codified in Розенталь/Лопатин above.
|
||||
- **[LB]** The Палладий (палладица) system is the generally accepted and de-facto only system for writing Chinese proper names in Russian, used across official documents AND художественные произведения; its purpose is unification, not phonetic fidelity, and full pinyin→palladica tables exist as machine-usable data.
|
||||
- Источник (practitioner): https://ru.wikipedia.org/wiki/Транскрипционная_система_Палладия — «Транскрипционная система Палладия»; tables: https://cidian.ru/palladius and https://studychinese.ru/palladij/
|
||||
- Каветы: Wikipedia is tertiary but uncontested on this point; ekd.me (https://ekd.me/2019/11/palladij-velikij-i-uzhasnyj-pochemu-nuzhno-znat-kitajsko-russkuyu-transkripciyu/) confirms from practitioner side. Because tables are deterministic, palladica conformance of names is checkable in Go code without model calls.
|
||||
- **[LB]** The Поливанов system is the dominant standard for Japanese in Cyrillic; spellings like «ши/чи» arise from re-transcribing Hepburn romanization when names are taken from ENGLISH intermediate sources and are rejected by professional linguists — i.e., an en-pivot pipeline systematically leaks non-standard Japanese name forms into Russian.
|
||||
- Источник (practitioner): https://ru.wikipedia.org/wiki/Система_Поливанова — «Система Поливанова»
|
||||
- Каветы: Fandom enforcement is contested (си/ши holy wars documented, e.g., moluch.ru/archive/157/44284); some fan communities deliberately prefer Hepburn-derived forms, so the glossary should treat the transcription system as a per-book policy choice, deterministically enforced once chosen.
|
||||
- **[ ]** Peer-reviewed study of realia translation in xianxia webnovels into Russian (Маслахова & Баймуратова, 2022, «Современные исследования социальных проблем»; corpus: «Основатель Тёмного Пути» Мосян Тунсю and «Божественный доктор: дочь первой жены») found four strategies — calque/neologism, descriptive, approximate (genus-species), contextual — and estimated ~5–7 translator footnotes per chapter are needed for culture-bound terms.
|
||||
- Источник (paper): https://cyberleninka.ru/article/n/sposoby-perevoda-realiy-v-kitayskih-novellah-na-angliyskiy-i-russkiy-yazyki — «Способы перевода реалий в китайских новеллах на английский и русский языки»
|
||||
- Каветы: Two-novel corpus, no percentages; the 5–7 footnotes figure is the authors' approximation, not a measured distribution.
|
||||
- **[LB]** Professional Russian translators of Chinese novels (interviews, Афиша Daily) name the multi-appellation naming system as a core difficulty — one character (e.g., Lan Wangji) carries about six designations (birth name, courtesy name, title, А-/-эр diminutives) — plus dense classical-literature allusions; so a book glossary must model alias clusters per character, not 1:1 name mappings.
|
||||
- Источник (blog): https://daily.afisha.ru/culture/29013-nebozhiteli-demony-i-cenzura-kak-ustroeny-kitayskie-novelly-kotorye-chitayut-vse/ — «Небожители, демоны и цензура: как устроены китайские новеллы»
|
||||
- Каветы: Journalism with named translator interviews (Юлия Каретникова, Евгения и Ольга Сойкины), not a study; the six-designation example is from the article's own illustration.
|
||||
- **[ ]** tl.rulate.ru (the main Russian collective webnovel-translation platform) documents: team access-right tiers with four member statuses, translation moderators, per-fragment reader error reports with typed error categories routed to the project owner for acceptance, and a separate «AI-переводы» catalog category segregating machine translations.
|
||||
- Источник (official-doc): https://tl.rulate.ru/site/help — «Как пользоваться сайтом», Tl.Rulate.ru
|
||||
- Каветы: The public help page does not document project glossaries in detail, though search snippets indicate per-project glossaries editable by the team exist; could not verify structure without login.
|
||||
- **[ ]** The Rulate community itself teaches translators standard Розенталь dialogue formatting — new line plus тире per reply, period changed to comma before attribution, capitalization patterns after attribution breaks — plus a stated allowance to render 2–3 short exchanges in-line with кавычки; i.e., readers of translated webnovels expect canonical Russian dialogue typography, and community norms match the codified rules.
|
||||
- Источник (practitioner): https://tl.rulate.ru/users/191249/blog/852 — «Как писать диалоги», Rulate user blog
|
||||
- Каветы: Community blog, not platform policy; but it independently reproduces Розенталь §§ 47–52, confirming those rules are the live community norm, not just prescriptive theory.
|
||||
- **[LB]** wuxiaworld.ru's documented crowd-editing workflow targets, in this order: grammar/spelling (LanguageTool recommended), mass replacement of character names and foreign terms via comment requests, character GENDER/pronoun errors, and empty-paragraph cleanup — direct community evidence that gender-agreement drift and name inconsistency are the dominant visible defects of machine/amateur translation into Russian.
|
||||
- Источник (official-doc): https://wuxiaworld.ru/redaktirovat-ranobe-novelly-manga/ — «Как редактировать Новеллы и Ранобэ», WuxiaWorld.ru
|
||||
- Каветы: Fan-site help page, not a measured defect taxonomy; but it converges with the VseGPT vendor statement below from an independent origin.
|
||||
- **[LB]** VseGPT's Нейропереводчик tool (LLM translation of novels with glossary injection into the prompt) states as its motivating problems: MT confuses character gender («мужчина/женщина»), translates the same term differently across passages, and violates fandom conventions from previous translators — the exact failure modes a deterministic glossary + cohesion checker must catch.
|
||||
- Источник (official-doc): https://vsegpt.ru/ExtTools/Neurotranslator — «Нейропереводчик с Глоссарием для переводов новелл», VseGPT; peer service: https://mlate.ru/ — «MLate.ru — Умный машинный перевод новелл и ранобэ»
|
||||
- Каветы: Vendor documentation with marketing flavor; no numbers. mlate.ru could not be fetched (socket errors) — existence confirmed via search only. Gender-confusion claim independently corroborated by wuxiaworld.ru editing docs (separate origin).
|
||||
- **[LB]** Chinese lacks grammatical tense; aspectual meaning is carried by markers 了/着/过 which do not map one-to-one onto the Russian perfective/imperfective + 3-tense system (imperfective: past/present/future; perfective: past/future) — so narrative tense and aspect in the Russian target are translator-created artifacts requiring contextual inference, with no source-side anchor to check against.
|
||||
- Источник (paper): https://cyberleninka.ru/article/n/kategoriya-vida-v-grammatike-kitayskogo-i-russkogo-yazykov — Пэн Фань, «Категория вида в грамматике китайского и русского языков», Челябинский гуманитарий, 2017; tense system: https://journals.susu.ru/lcc/article/view/434/567 — Лян, «Способы выражения времени глагола в русском и китайском языках»
|
||||
- Каветы: Contrastive-grammar papers, not corpus measurements of translation errors; the design implication (tense flips at chunk seams) is an inference from the grammar contrast plus community defect evidence, not itself measured.
|
||||
- **[ ]** Paragraph division in Russian is a compositional-stylistic, author-controlled device distinct from semantic-syntactic segmentation — the same text may legitimately be paragraphed differently — which legitimizes re-paragraphing one-sentence-per-paragraph CJK webnovel prose during translation rather than mirroring source line breaks.
|
||||
- Источник (paper): https://evartist.narod.ru/text14/11.htm — Валгина Н. С., «Теория текста», гл. «Абзац как композиционно-стилистическая единица текста»
|
||||
- Каветы: Quote taken from search-result rendering of the textbook chapter; full page not independently re-fetched. This is general text theory — no source found that specifically documents HOW ru webnovel translators merge paragraphs (see gaps).
|
||||
- **[ ]** Russian fan translations of webnovels/ranobe are predominantly made from the English translation (анлейт), not the original zh/ja, and readers attribute terminology calques and quality loss to this English pivot plus undisclosed machine translation sold as paid chapters.
|
||||
- Источник (blog): https://pikabu.ru/story/kak_perevodit_novellyi_6683217 — «Как переводить новеллы» (Пикабу); ecosystem map: https://xianxiaru.wordpress.com/сылки-на-сайты-с-переводами-и-не-только/ — Xianxia links page
|
||||
- Каветы: Pikabu page fetch returned truncated content; quote is from the search snippet of that guide. Converging but anecdotal signals from XGM review of «Martial Peak» (403 on fetch) and Rulate forums; no systematic survey exists. One voice per source, low rigor.
|
||||
854
docs/research/19-chunking-cohesion.md
Normal file
854
docs/research/19-chunking-cohesion.md
Normal file
|
|
@ -0,0 +1,854 @@
|
|||
# research/19 — Логическая нарезка, меж-чанковая когезия, контракт t/e и дизайн эмпирики (трек B, D39)
|
||||
|
||||
> Сессия-ресёрчер, 2026-07-16. Промт: `docs/RESEARCHER_CHUNKING_COHESION_SESSION_PROMPT.md`.
|
||||
> НЕ коммитится этой сессией — лендит оркестратор после верификации первоисточников.
|
||||
>
|
||||
> **Протокол независимости (анти-анкоринг, как research/18):** §A написан и заморожен sha256 ДО чтения
|
||||
> стека проекта (код `backend/`, `docs/architecture/*`, `docs/experiments/*`, `docs/research/1-18`).
|
||||
> Верификация заморозки (в команде `[ ]` = пробел — чтобы сама команда, процитированная здесь, не совпадала с маркером):
|
||||
> `sed -n '/<!-- SECTION-A-FROZEN-BEGIN[ ]-->/,/<!-- SECTION-A-FROZEN-END[ ]-->/p' docs/research/19-chunking-cohesion.md | sed '1d;$d' | sha256sum`
|
||||
> — хеш зафиксирован в примечании сразу после закрывающего маркера §A.
|
||||
>
|
||||
> **Поверхность заражения (декларация):** до заморозки §A сессия видела ТОЛЬКО (а) текст промта
|
||||
> (он содержит сводку конфликта exp14 §2Б.4 vs research/18 §A Ось-4, факты полигон-синка, константу
|
||||
> `targetChunkTokens=1500` и список ролей пайплайна) и (б) CLAUDE.md + MEMORY.md (онбординг-контекст).
|
||||
> Ни один файл стека не открывался. Внешняя фактура §A добыта веб-ресёрчем этой сессии:
|
||||
> 8 тем × fan-out + адверсариальная верификация несущих клеймов по первоисточникам (author≠reviewer:
|
||||
> верификатор обязан был РЕФЬЮТИТЬ клейм по первоисточнику; вердикты CONFIRMED/OVERSTATED с коррекциями
|
||||
> отмечены по тексту) + critic-раунд добора (CJK-примитивы, diff-контракт, методология, русские нормы).
|
||||
|
||||
<!-- SECTION-A-FROZEN-BEGIN -->
|
||||
## §A — Независимое заключение (ЗАМОРОЖЕНО)
|
||||
|
||||
### A.0 Резюме в одно предложение
|
||||
|
||||
Конфликт «крупный чанк vs мелкий чанк» — ложная дихотомия, потому что слово «чанк» склеивает три
|
||||
независимых параметра: **единицу эмиссии** (сколько модель порождает за вызов), **окно чтения**
|
||||
(сколько она видит) и **единицу связности** (сцена/глава); правильный дизайн — детерминированная
|
||||
нарезка по иерархии границ с оптимизационной упаковкой, мелкая-средняя эмиссия, широкое read-only
|
||||
окно там, где проход этого требует, и когезия, подаваемая МЕХАНИЗМОМ (структурированный стейт +
|
||||
замок терминов + carryover), а не размером единицы.
|
||||
|
||||
### A.1 Три размера вместо одного (разрешение центрального конфликта)
|
||||
|
||||
Внешняя эмпирика расщепляет конфликт по осям:
|
||||
|
||||
1. **Единица эмиссии — связывает раньше всего.** Качество длинной генерации падает задолго до
|
||||
документированных лимитов output-токенов: у семи open-weight моделей — резкая деградация перевода
|
||||
на 4k–8k контекста с доминированием omission/under-translation (SEGALE, arXiv:2509.17249);
|
||||
структурированная генерация: open-weight модели сыпятся уже на 2k output-токенов, GPT-4o заметно
|
||||
деградирует на 8k (LongProc, arXiv:2501.05414); выровненные модели 2024 упирались в ~2000 слов
|
||||
(LongWriter, arXiv:2408.07055); окно в 50 предложений теряло 10 предложений перевода при полном
|
||||
исходнике на входе (DelTA, arXiv:2410.08143); paragraph-mode у Karpinska & Iyyer (WMT 2023,
|
||||
aclanthology 2023.wmt-1.41) дал МЕНЬШЕ mistranslation/grammar/consistency-ошибок, чем sentence-mode,
|
||||
но omission были ЗАМЕТНЕЕ (вердикт верификатора: в обоих режимах есть, в paragraph — чаще).
|
||||
У doc-MT деградация концентрируется в ХВОСТЕ документа (position bias: поздние предложения
|
||||
переводятся хуже; arXiv:2412.17592). → Выгода крупной единицы эмиссии съедается тихими потерями,
|
||||
и потери смещены к концу чанка.
|
||||
2. **Окно чтения — дешевле, чем кажется (кэш), но не бесплатно.** Все четыре провайдера пайплайна
|
||||
кэшируют префикс запроса (официальные доки: Anthropic prompt-caching; OpenAI automatic caching;
|
||||
DeepSeek context caching «hit» ~1–2% цены miss на live-странице июля 2026 — перепроверить перед
|
||||
зашивкой в COGS; Gemini implicit caching), поэтому статичный префикс (система+глоссарий) почти
|
||||
бесплатен при последовательной обработке. Но большое окно чтения не бесплатно по КАЧЕСТВУ:
|
||||
на 2025-моделях деградация с ростом входа сохраняется (Context Rot, Chroma, 18 моделей, июль 2025),
|
||||
и хуже всего — ассоциации с НИЗКИМ лексическим перекрытием (NoLiMa, arXiv:2502.05167: эффективная
|
||||
длина GPT-4.1 ~16k при заявленном 1M), а кросс-язычный глоссарий/память — ровно этот режим.
|
||||
→ Read-only контекст держать МАЛЫМ и СЕЛЕКТИВНЫМ, статику — в начало, чанк — в конец
|
||||
(U-кривая Lost in the Middle, arXiv:2307.03172, скоуп — retrieval/QA, не генерация — не
|
||||
овер-обобщать).
|
||||
3. **Единица связности — не равна ни тому, ни другому.** 7% пар последовательных предложений,
|
||||
хороших по отдельности, ломаются в контексте; из них дейксис 37%, эллипсис 29%, лекс. когезия 14%
|
||||
(Voita et al., ACL 2019, P19-1116 — вердикт: CONFIRMED, ставка 7% от всех пар, не 8.5%).
|
||||
Триггерящий контекст в тест-сетах — ≤3 предложения НАЗАД (дизайн-выбор сета, не природная
|
||||
дистанция); наибольший прирост использования контекста даёт ПЕРВОЕ предыдущее предложение,
|
||||
дальше — убывающая отдача, target-side контекст используется чуть сильнее source-side
|
||||
(CXMI, Fernandes et al., ACL 2021 — вердикт OVERSTATED в части BLEU-дельт, направление
|
||||
подтверждено). Катафора: ~16% местоимений в субтитрах — катафорические, ~37% из них разрешаются
|
||||
СЛЕДУЮЩИМ предложением; +1 предложение вперёд давало измеримый прирост (Wong, Maruf & Haffari,
|
||||
ACL 2020 — CONFIRMED). Длинные зависимости (имена/термины/титулы) закрываются не окном, а
|
||||
ЗАМКОМ первого перевода: proper-noun record даёт +48.5пп консистентности имён на вебновелл-сете
|
||||
(DelTA, GuoFeng) — а в вебновелл-домене именованные сущности + терминология = 62.5% document-level
|
||||
ошибок (BWB, arXiv:2305.11142). → Когезию несут: carryover 1–3 предложения (билингвально,
|
||||
target-side важнее), lookahead ~1 предложение вперёд, замок терминов, — а не рост единицы эмиссии.
|
||||
|
||||
**Следствие-развязка:** проходам, которым нужно «видеть много» (репараграфизация, сведение связей),
|
||||
не обязательно «переписывать много»: они могут читать сцену/главу и эмитить компактные правки.
|
||||
Наблюдение «крупнее чанк → лучше абзацы» объясняется шириной ОКНА ЧТЕНИЯ у reflow-решений, а
|
||||
«держать чанк мелким» — рисками крупной ЭМИССИИ (ретрай-радиус, omission-хвост). Оба совместимы.
|
||||
Это ПРОВЕРЯЕМОЕ утверждение, и эмпирика §D обязана его проверить, а не принять на веру.
|
||||
|
||||
### A.2 Что говорит внешняя фактура о САМОЙ нарезке
|
||||
|
||||
- **Семантик-чанкинг модель-вызовами не окупается.** Контролируемое сравнение fixed vs semantic:
|
||||
преимущества нет на естественных документах, выигрыши только на искусственно склеенных корпусах
|
||||
(arXiv:2410.13070 — CONFIRMED). LumberChunker (LLM-сегментация нарратива, arXiv:2406.17526 —
|
||||
CONFIRMED) даёт +7.37% DCG@20, но retrieval-only и ценой LLM-вызовов на каждый документ. Вся эта
|
||||
литература — RAG/retrieval; её метрики (recall/IoU) к последовательному полнопокрывающему переводу
|
||||
неприменимы. → Ограничение владельца «границы без модель-вызовов» подтверждается как норма,
|
||||
а не компромисс: индустрия сегментации (SRX, ICU-regex правила) сама детерминированная.
|
||||
- **«Найти сцену» алгоритмически — нельзя рассчитывать.** Первый корпус сцен художки: BERT F1=24%
|
||||
(Zehe et al., EACL 2021 — CONFIRMED); shared task STSS 2021: лучшие F1=37% in-domain / 26%
|
||||
out-of-domain, у людей γ=0.7 (CEUR-WS Vol-3001 — CONFIRMED); NAACL 2025 follow-up: Llama-класс
|
||||
задачу не решил. Вся линейка — одна research-группа (одна нога литературы). GraphSeg на
|
||||
синтетике Pk 5.6–7.2, на естественных документах — ХУЖЕ рандома (Pk 63.56 vs 52.65; Koshorek
|
||||
NAACL 2018 — CONFIRMED). → Дизайн, ЗАВИСЯЩИЙ от верной детекции сцен, построен на песке.
|
||||
Правильная роль сигналов: поверхностные маркеры — высокоточные, когда есть; лексические долины —
|
||||
только РАНЖИРУЮТ кандидатов возле бюджета; всё валидируется на СВОЁМ корпусе, не на Choi-бенчах.
|
||||
- **Поверхностные конвенции доменов реальны и детектируемы.** en-фикшн: сцен-брейк = видимый токен
|
||||
(#/***; Shunn manuscript format). ja-вебновеллы: пустые строки —ШУМ (просто читабельность каждые
|
||||
5–10 строк), сцен-смена — выделенные разделители *◇◆■○ (Syosetu-гайды). zh-вебновеллы: главы
|
||||
короткие (~2–5k иероглифов, «десять минут чтения»), конвенция 一句一段 (одно предложение — один
|
||||
абзац) → абзацная граница ≈ границе предложения, слабый сигнал; 分割线-орнаменты встречаются.
|
||||
Академической корпусной статистики по zh/ja вебновелл-форматированию НЕТ — только
|
||||
практикумы/платформы (слабая нога; для нас это довод строить рантайм-ПРОФИЛЬ структуры, а не
|
||||
зашивать конвенции). Для zh тема-сегментация работает на символьных биграммах БЕЗ словосегментации
|
||||
и даже лучше словной (+8.84% F, TDT2 broadcast news; одна группа NWPU — одна нога) → Go-скорер
|
||||
когезии на char-биграммах легитимен для zh/ja/ru единым кодом.
|
||||
- **CJK-примитивы предложения — решённая задача с известными краями.** UAX #29: 。!? = STerm;
|
||||
закрывающие 」』)" присоединяются к терминатору (SB9–SB11: разрез ПОСЛЕ 「…。」, не после 。);
|
||||
без терминальной пунктуации внутри абзаца дефолт НЕ даёт границы (SB998), граница абзаца/строки —
|
||||
легальный последний рубеж (CONFIRMED по TR29 + UCD). Pure-Go база есть (clipperhouse/uax29,
|
||||
Unicode 17, официальные тест-сьюты). Замер ja-сегментеров: у всех rule-based нулевые F1-классы
|
||||
(эмодзи/каомодзи/переносы строк — ровно вебновелл-стиль) → сегментер обязан деградировать в
|
||||
«абзац = граница», а не гадать. Оверсайз-предложение zh: запятая — документированная клаузная
|
||||
граница, но классификация запятых даже с ML ~87% (SIGHAN 2004) → детерминированный разрез по
|
||||
,、;: допустим только как soft-граница с флагом, не как «предложение».
|
||||
- **Токен-бюджет считается оффлайн точно для 3 из 4 вендоров.** DeepSeek — официальный оффлайн-токенайзер
|
||||
(+официальная эвристика zh≈0.6 tok/char); GLM — tiktoken-совместимый rank-формат (загружаем
|
||||
pkoukk/tiktoken-go); OpenAI — tiktoken-go с вшитыми словарями. Gemini — SentencePiece, Go-пакет
|
||||
качает модель в рантайме, покрытие 2.x/3.x не верифицировано; замер на одном тексте: Gemini тратит
|
||||
в 2–2.8× больше токенов на CJK-символ, чем DeepSeek (один датапоинт, реселлер-блог) → для Gemini —
|
||||
вендоренная модель или замеренный ratio с запасом ~20–30%. Кросс-вендорный разброс chars/token
|
||||
для zh — до ~70% (cl100k 2.08× → o200k 1.34× vs английский) → единая константа chars/token
|
||||
НЕБЕЗОПАСНА; калибровка per-language × per-vendor, замеренная на СВОЁМ вебновелл-тексте.
|
||||
Для русского ВЫХОДА опубликованных ratio нет — замерить локально оффлайн-токенайзерами.
|
||||
|
||||
### A.3 Дизайн-вывод: алгоритм нарезки (детерминированный Go, без модель-вызовов)
|
||||
|
||||
Инварианты: (i) никогда не резать внутри предложения; (ii) общность — алгоритм характеризует ЛЮБОЙ
|
||||
вход в рантайме, никакого тюнинга под книгу; (iii) детерминизм — одинаковый вход → байт-идентичные
|
||||
чанки со стабильными ID; (iv) при недоступности сильных сигналов поведение деградирует к
|
||||
«не хуже жадной упаковки по абзацам», с телеметрией деградации.
|
||||
|
||||
**Шаг 0. Нормализация + структурный профиль (книга/глава).** Unicode-нормализация, унификация
|
||||
переносов; профиль: распределение длин абзацев в токенах, медиана предложений на абзац
|
||||
(line-per-sentence-детект), доля диалоговых строк (「」『』«»"—), плотность и словарь явных
|
||||
разделителей (пустые строки ≥2, орнаменты ***/*/◇/◆/■/○/分割线, внутриглавные заголовки),
|
||||
отношение размера главы к бюджету. Профиль — ВХОД детектора (какие сигналы в этой книге
|
||||
информативны), не приговор книге.
|
||||
|
||||
**Шаг 1. Кандидаты границ с классами силы.**
|
||||
- **B0 жёсткая структурная**: граница главы/части; явный разделитель (орнамент-строка, ≥2 пустые
|
||||
строки там, где профиль говорит «пустая строка ≠ шум»).
|
||||
- **B1 вероятная сцен-граница**: маркеры сдвига время/место/POV в начале абзаца (per-language
|
||||
лексиконы: 次日/翌朝/三年后/一方/こうして/Наутро/…), переход диалоговый-блок→нарратив,
|
||||
разделители, которые профиль отнёс к слабым.
|
||||
- **B2 тема-сдвиг**: долина лексической когезии TextTiling-типа на скользящих окнах
|
||||
(zh/ja — символьные биграммы; en/ru — стем-токены) + обрыв цепочек упоминаний сущностей
|
||||
(имена из глоссария книги). Только z-score-глубокие долины; сигнал РАНЖИРУЕТ, не утверждает.
|
||||
- **B3 граница абзаца** (в line-per-sentence-режиме — группы строк, склеенные диалоговым контекстом).
|
||||
- **B4 граница предложения** (UAX #29 + CJK-tailoring: Close*-присоединение, 。!?…‼⁇, кавычко-осознанность,
|
||||
аббревиатуры en/ru).
|
||||
- **B5 внутри предложения — разрез запрещён.** Если предложение одно > hardMax: аварийный
|
||||
клауза-сплит по ;:,、 с флагом `oversized_sentence` (телеметрия, деградация не молчит).
|
||||
- **Диалог-констрейнт:** реплики одного обмена (turn-run) — связка; разрез внутри обмена штрафуется
|
||||
сильнее, чем между обменами; реплика не отрывается от атрибуции (слов автора), идентифицирующей
|
||||
говорящего. (Прецедент кодифицируемости таких запретов — Netflix TTSG: «не отрывать X от Y»
|
||||
как конечный список правил.)
|
||||
|
||||
**Шаг 2. Упаковка — оптимизация, не жадность.** DP по кандидатам границ (аналог Кнута-Пласса):
|
||||
`cost(chunk) = w_size·f(|tokens−target|; недобор дешевле перебора; жёсткие min/hardMax)
|
||||
+ w_bound·penalty(класс правой границы: B0=0 < B1 < B2 < B3 < B4)
|
||||
+ w_dialog·(разрез внутри диалогового обмена)`.
|
||||
Глобальный минимум суммарной стоимости по главе, O(N·W). Хвост < min — перебалансировка последних
|
||||
двух чанков, не огрызок. Выход: чанки со стабильными content-hash ID + классом правой границы
|
||||
(доля разрезов по B0–B2 vs B3–B4 — наблюдаемая метрика качества нарезки в телеметрии).
|
||||
Бюджеты: target/min/hardMax в токенах ЦЕЛЕВОГО вендора (оффлайн-токенайзер, A.2), и отдельно —
|
||||
прогноз ВЫХОДНОГО размера (ru-ratio × source) против выходного лимита качества, потому что
|
||||
связывает выход (A.1.1): практический стартовый ориентир — эмиссия ~1–3k output-токенов у дешёвых
|
||||
моделей, точное значение — калибровать на полигоне (кривая уже частично есть).
|
||||
|
||||
**Шаг 3. Фоллбек-лестница (полный веер кейсов).**
|
||||
| Кейс | Поведение |
|
||||
|---|---|
|
||||
| глава ≤ target | 1 чанк (тривиальный) |
|
||||
| глава > target, есть B0/B1 | резать по ним; сцена > target → внутрь B2/B3 |
|
||||
| плоский текст (профиль: line-per-sentence, сцен-маркеров нет) | B2-ранжирование возле бюджета; долины мельче порога → честный B3/B4 через DP (= не хуже жадности) + телеметрия «граница слабая» |
|
||||
| мега-абзац > hardMax | B4 внутри абзаца |
|
||||
| мега-предложение > hardMax | клауза-сплит + флаг |
|
||||
| стихи/песни/письма (плотные короткие строки без терминаторов) | блок целиком, не резать |
|
||||
| эпиграфы/авторские примечания/анонсы | отдельный класс чанка (не смешивать со сценой) |
|
||||
| смешанные конвенции внутри книги | профиль пересчитывается по главе, не по книге целиком |
|
||||
|
||||
### A.4 Дизайн-вывод: меж-чанковая когезия
|
||||
|
||||
Пакет контекста на чанк — весь read-only, порядок от статичного к волатильному (закон всех четырёх
|
||||
кэшей; брейкпоинт Anthropic — на последнем СТАБИЛЬНОМ блоке):
|
||||
|
||||
1. **Статика роли** (system, конвенции, мандаты) — кэшируется всегда.
|
||||
2. **Книжная статика** (глоссарий с замком первого утверждённого перевода; версия = снапшот;
|
||||
сортировка ключей детерминированная — пере-сортировка ломает кэш-префикс). Замок терминов —
|
||||
самый измеренный механизм когезии (DelTA +48.5пп LTCR-1 на вебновеллах; победители WMT24 —
|
||||
терминологические таблицы + editor/critic-агенты). ВАЖНО: LTCR-меряет «залочились на первом
|
||||
переводе», не «первый перевод верен» → гейт draft→approved на первом вхождении — реальная
|
||||
защита от отравления замка. Записи глоссария — кластеры алиасов на СУЩНОСТЬ (имя, курт. имя,
|
||||
титул, А-/-эр-диминутивы), с полом персонажа как первоклассным полем (см. A.6).
|
||||
3. **Структурированный стейт сцены — слоты, не свободная проза**: кто-на-сцене/где/когда/открытые
|
||||
нити/регистр; билингвальные пары терминов сцены. Инкрементальный свободный running-summary —
|
||||
измеренно худший носитель: удваивает omission-ошибки vs иерархическая сборка (BooookScore,
|
||||
ICLR 2024 — CONFIRMED: entity omission 7.3% vs 3.71% и т.д.), слепое слияние без источника
|
||||
амплифицирует галлюцинации, ре-граундинг чинит (Ou & Lapata 2025). → Стейт собирается
|
||||
детерминированно из банка памяти/источника (перегрунтовка каждый чанк), НЕ LLM-пересказом
|
||||
поверх LLM-пересказа.
|
||||
4. **Carryover**: хвост предыдущего чанка — последние K предложений источника + их УТВЕРЖДЁННЫЙ
|
||||
перевод (билингвально; target-side важнее source-side — Fernandes/DocRepair). K малое (1–3
|
||||
предложения; DelTA STM k=3), адаптивно к классу границы (через B0 — можно меньше).
|
||||
5. **Lookahead +1** (арм эмпирики): первые M предложений следующего чанка, только источник —
|
||||
единственный механизм против катафоры/zh zero-anaphora вперёд (Wong 2020: next-sentence
|
||||
помогает; в zh-диалогах опущено ~26% местоимений — survey arXiv:2305.10196).
|
||||
6. **Сам чанк** — волатильная часть, всегда cache-miss, это нормально.
|
||||
|
||||
Деньги/детерминизм: пп.2–5 — производные источника и уже ПРИНЯТЫХ переводов (фолд в снапшот);
|
||||
ретрай чанка не меняет вход соседей (carryover фиксируется порядком обработки); ретрай —
|
||||
байт-идентичным телом (любая приписка «почему упало» — в конец, иначе ломает кэш-префикс);
|
||||
параллельный фан-аут платит полный input N раз, пока кэш не прогрет → warm-then-fan
|
||||
(первый вызов прогревает префикс, остальные стартуют после первого токена ответа) — это
|
||||
прямой конфликт с идеей «параллелизм ради скорости» и обязан попасть в COGS-модель V4.
|
||||
|
||||
### A.5 Дизайн-вывод: контракт переводчик/редактор
|
||||
|
||||
- **Черновик — верный и СТРУКТУРНЫЙ**: 1:1 по предложениям/абзацам источника со стабильными ID
|
||||
сегментов (иначе диффы редактора не адресуемы и omission не детектируем кодом). Paragraph-level
|
||||
вход переводчику (не предложение): 71.1% предпочтения проф-переводчиков, в 12× меньше
|
||||
consistency-ошибок (Karpinska & Iyyer) — но с omission-гардом, потому что paragraph-mode
|
||||
роняет контент чаще sentence-mode.
|
||||
- **Редактор — узкие мандаты, эмиссия = операции, не полный текст.** Ключевая внешняя опора:
|
||||
на сильном черновике en→ru НИ ОДНА APE-система WMT19 не побила do-nothing (16.16 TER/76.20 BLEU;
|
||||
W19-5402 — CONFIRMED), а овер-коррекция — именованная главная проблема APE; LLM-редакторы
|
||||
правят даже заведомо корректный вход (Ki & Carpuat 2024). → (а) у редактора обязан быть
|
||||
первоклассный выход «нет правок»; (б) каждый арм редактуры в эмпирике меряется ПРОТИВ
|
||||
do-nothing-арма; (в) формат «сначала перечисли правки, потом применяй» режет объём правок
|
||||
на ~¼–⅓ без потери качества (Raunak et al. 2023, с коррекциями верификатора).
|
||||
- **Формат диффа — анchored search/replace, НЕ line numbers.** Search/replace-блоки — самый надёжно
|
||||
ЭМИТИРУЕМЫЙ формат на всех размерах моделей (Diff-XYZ, JetBrains 2025: EM 0.68–0.95 generation);
|
||||
mid-tier модели держат 91–98% формат-комплаенса (aider polyglot; DeepSeek-класс 98.2%); оба вендора
|
||||
тренируют модели на context-anchored форматах без номеров строк; применяет — детерминированный
|
||||
Go-apply с ТОЛЕРАНТНЫМ поиском якоря (нормализация пробелов; у aider отключение fuzzy-apply
|
||||
давало 9× больше ошибок) + validate-retry-reject на 2–9% малформед-правок. Слабые модели ниже
|
||||
формат-пола → фоллбек full-regen с anti-omission гардами. Якоря должны быть уникальны в чанке —
|
||||
ещё один довод держать чанк умеренным. Всё это измерено на КОДЕ; на русской прозе бенчмарка не
|
||||
существует → это арм эмпирики, не пресуппозиция.
|
||||
- **Reflow/репараграфизация — отдельный проход «широкое чтение / узкая эмиссия»**: читает сцену/главу,
|
||||
эмитит план переверстки (какие сегменты сливать/делить), применяет код. Это прямой тест развязки
|
||||
A.1: если выигрыш «крупного чанка» по абзацам воспроизводится крупным ОКНОМ при мелкой ЭМИССИИ —
|
||||
конфликт снят. Перепараграфизация под целевые конвенции — легитимная переводческая работа
|
||||
(сплошная практика для zh→en/ru; у русского абзаца — своя композиционная логика), и она
|
||||
ТРЕБУЕТ, чтобы когезия/выравнивание не были прибиты к 1:1 абзацному соответствию.
|
||||
- **Арм «сильный переводчик отдаёт структуру»** — единственное плечо без единого датапоинта
|
||||
(полигон-синк, факт 1): черновик, уже несущий дискурс-решения, может сделать
|
||||
редактора-переписывателя ненужным. Обязателен в §D.
|
||||
|
||||
### A.6 Дизайн-вывод: русская целевая сторона — детерминированные линты (дёшево)
|
||||
|
||||
Русская типографика диалога — замкнутая, регексуемая грамматика (Розенталь §§47–52; ПАС Лопатина
|
||||
§§154–157 — верифицировано по old-rozental.ru/orthographia.ru, с одной коррекцией: двоеточие
|
||||
лицензируется не только глаголами речи): «— » в начале реплики-абзаца; швы атрибуции «, —»/«? —»/
|
||||
«! —»/«… —» с регистровыми констрейнтами; «?!» в этом порядке; «?..»/«!..» ровно с двумя точками;
|
||||
запятая поглощается многоточием. → Санитайзер/линтер в Go без модель-вызовов, около-нулевые
|
||||
ложные срабатывания. Дальше: пол персонажа — первоклассное детерминированное поле банка памяти
|
||||
(«пошёл/пошла» — самый видимый класс дефектов МП в ru по двум независимым источникам:
|
||||
wuxiaworld.ru-редактура и VseGPT-глоссарий-тул); транскрипция имён — Палладий (zh) / Поливанов (ja)
|
||||
как машинные таблицы + детект англо-пивотных артефактов («ши/чи» из Хэпбёрна) с per-book
|
||||
policy-флагом (фандомные конвенции бывают сильнее нормы); китайский бестенсовый → время/вид в ru —
|
||||
изобретение переводчика, консистентность определена только ВНУТРИ сцены → линт тенс-флипов в
|
||||
пределах сцены, ещё один довод резать по сцен-границам. Реплика+атрибуция — неделимая единица
|
||||
и для ЧАНКЕРА (диалог-констрейнт A.3 получает независимое обоснование от целевой типографики).
|
||||
|
||||
### A.7 Принципы эмпирики (§D обязан их конкретизировать)
|
||||
|
||||
- **Пары, кластеры, мощность.** Анализ — на ПАРНЫХ по-главных разностях против общего якоря
|
||||
(Miller, arXiv:2411.00640 — CONFIRMED: naive SE занижает до 3.05×); SE кластеризуются по книге;
|
||||
мощность считается парной формулой (не «unpaired × (1−ρ)» — ошибка ~2×); армы одного пайплайна —
|
||||
«related systems» → K>1 повторов судьи на пару даёт до ~6× меньший детектируемый эффект почти
|
||||
бесплатно (Wang, arXiv:2512.21326).
|
||||
- **Судья.** Пары — в ОБОИХ порядках (position bias в одиночку переворачивал 66/80 вердиктов;
|
||||
arXiv:2305.17926), температура 0, ~10 повторов с мажоритарным голосованием как стартовая норма
|
||||
(arXiv:2606.13685), leave-one-out по судьям, катастроф-скрин к победителю тоже; агрегация
|
||||
fidelity-first. Человеческое чтение — первичный эндпоинт когезии (WMT24 literary: людской и
|
||||
автоматический рейтинги расходятся; протокол 0–5 × {general, discourse} × проф-оценщики,
|
||||
κ=0.86 — прямой цитируемый образец).
|
||||
- **Стоимость.** Эндпоинт — Cost-of-Pass-стиль: ожидаемая цена ПРИНЯТОЙ главы = вся потраченная
|
||||
цена (включая ретраи и вызовы гейтов) / принятые главы (arXiv:2504.13359), ретраи и кэш-хиты
|
||||
репортятся отдельно, per-call кап, каждый скрипт персистит usage/cost.
|
||||
- **Трапы.** Маркированный набор КРОСС-ГРАНИЧНЫХ трапов, построенный ИЗ таксономии Voita +
|
||||
zh-специфики: анафора назад через границу, катафора вперёд, эллипсис/zero-anaphora, смена
|
||||
регистра, сущность-через-границу, тенс-консистентность сцены, пол персонажа. Каждый трап —
|
||||
с ожидаемым поведением; код ПРОВЕРЯЕТ до прогона, что трап реально пересекает границу
|
||||
тестируемой нарезки (иначе — снова неинформативный null).
|
||||
- **Корпус.** Вне претрейна, СТРУКТУРНО РАЗНООБРАЗНЫЙ (плоский CJK line-per-sentence /
|
||||
сцен-маркированный вебновелл / длинно-абзацный европейский / ja-ранобэ); плоская книга — одна
|
||||
точка спектра, не повод сузить продукт.
|
||||
- **Пре-регистрация.** Дизайн, армы, гипотезы, тесты, стоп-правило и мощность — заморожены
|
||||
коммитом ДО первого платного вызова (OSF-поля как чек-лист; van Miltenburg NAACL 2021).
|
||||
|
||||
### A.8 Фальсификаторы этого заключения
|
||||
|
||||
1. Q2 покажет, что крупная эмиссия выигрывает и на retry-adjusted COGS, и без роста omission
|
||||
(гарды молчат) → развязка A.1 не нужна, «edit=глава» легитимен для дешёвых моделей.
|
||||
2. Diff-редактура на русской прозе систематически ломается (формат-комплаенс < ~90%, apply-reject
|
||||
высокий, или правки-диффы проигрывают full-regen по качеству) → контракт A.5 откатывается к
|
||||
full-regen + anti-omission гардам; остаётся do-nothing-гейт.
|
||||
3. B2-сигнал (тема-долины) на реальных вебновеллах неотличим от шума → лестница живёт на
|
||||
B0/B1/B3 + DP (всё ещё лучше жадности), «логическая нарезка» = сцен-маркеры + упаковка.
|
||||
4. Carryover+стейт НЕ чинит трапы, которые чинит крупное окно (Q3-null при Q2-эффекте) → когезия
|
||||
требует окна; правильная форма — «широкое чтение + узкая эмиссия» в одном вызове (дороже по
|
||||
входу, но кэш-френдли), т.е. развязка сохраняется, меняется носитель.
|
||||
5. Профиль-детектор структуры нестабилен между главами одной книги (флип-флоп режимов) →
|
||||
профилирование поднять с главы на книгу/арку с гистерезисом.
|
||||
<!-- SECTION-A-FROZEN-END -->
|
||||
|
||||
> **Заморозка §A:** sha256 строк строго между маркерами (команда — в шапке файла) =
|
||||
> `1a46548aa75e7f35cc9efc451e9ae20c2ca040d718d0f3a8a686722a0a43f28b`, зафиксирован 2026-07-16, ДО открытия любого файла стека проекта.
|
||||
> Всё ниже написано ПОСЛЕ чтения стека.
|
||||
|
||||
---
|
||||
|
||||
## §B — Дифф §A↔стек + реализуемый Go-дизайн нарезки и когезии
|
||||
|
||||
### B0. Дифф замороженного §A против стека (честно)
|
||||
|
||||
**Прочитано после заморозки:** `09-target-architecture.md` (§0.1/§2/§4), `08-sync-audit-ledger.md` (L1/L2 целиком),
|
||||
`05-decisions-log.md` (D30–D39), код (`chunker.go`, `chunkrun.go`, `config/pipeline.go`, фрагменты
|
||||
`ingest.go`/`render.go`), `experiments/14-quality-empirics.md` (§2.3–2.7, §2Б), `research/18-quality-levers.md` §A.
|
||||
|
||||
**Сошлось (§A ⟂ стек, при декларированной общей ноге — промт нёс сводку конфликта):** развязка
|
||||
draft-единицы/edit-единицы = ратифицированная цель слоя 1 (D39 §4, бывший фантом «D35.7»); бюджет в
|
||||
выходных токенах как снапшот-folded кноб (09 §2 слой 1 ↔ §A.3 шаг 2); стратегия границы как first-class
|
||||
ось greedy|logical с фоллбек-лестницей и «никогда не резать предложение» (09 §2 ↔ §A.3); оживление
|
||||
`STMDepth`/`OverlapTokens` под carryover/summary (09 §2 ↔ §A.4); узкие мандаты + диффы у редактора
|
||||
(research/07 через ледджер L1 ↔ §A.5); детерминированные структурные KPI + линты русской типографики
|
||||
(09 слой 5 ↔ §A.6). Три размера из §A.1 (эмиссия/окно/связность) в стеке НЕ различались — там
|
||||
двумерное «draft-единица vs edit-единица»; трёхмерная декомпозиция — вклад этого отчёта, она и
|
||||
порождает недостающий арм Q2c (см. §D).
|
||||
|
||||
**Самопоправки §A после чтения кода (не меняют §A — фиксируются здесь):**
|
||||
1. **B4-примитив уже построен и хорош.** `splitSourceSentences` (`chunker.go:219-294`) уже реализует
|
||||
кавычко-осознанную сегментацию с поглощением закрывающих скобок (аналог UAX #29 SB9–SB11 Close*),
|
||||
depth-трекингом 「」『』“” и аббревиатурным гардом. §A.3-B4 = реюз этого кода, не переписывание.
|
||||
Недостающее против ja-краёв (эмодзи/каомодзи/безпунктуационные строки — нулевые F1-классы
|
||||
ja-senter-benchmark) закрывается фоллбеком B3 (граница строки/абзаца), уже совместимым с дизайном.
|
||||
2. **Sticky-scene уже есть зачаток структурного стейта.** `memory.Select` ведёт exact-match entity ids
|
||||
с пер-главным сбросом (`chunkrun.go:90`, bookrun) — слот «активные сущности сцены» из §A.4.3
|
||||
надстраивается над этим, а не с нуля.
|
||||
3. **Кривая exp14 мерила СКЛЕЕННУЮ величину.** В sizecurve рост «чанка» одновременно растил и окно
|
||||
чтения, и единицу эмиссии — ячейка «широкое окно × узкая эмиссия» пуста (это и есть Q2c).
|
||||
4. **⚠ НОВОЕ (несущее для §D): кривая exp14 §2Б.4 НЕ мерила omission по размерам.** «whole = 7782
|
||||
out-ток vs 800c = 15159» на ch17 — из чего сколько: снятый дублирующий overhead? слитые абзацы?
|
||||
или ТИХИЕ опущения? Внешняя эмпирика единодушно предсказывает рост опущений с размером эмиссии
|
||||
(Karpinska & Iyyer: omission заметнее в paragraph-mode; SEGALE: omission-доминированная деградация
|
||||
с длиной; DelTA: окно 50 предложений теряло 10 предложений перевода). Если часть «дешевизны»
|
||||
крупного чанка = невыплаченный контент, конфликт exp14↔research/18 разрешается сам собой.
|
||||
Q2 обязан прогнать omission-декомпозицию по размерам — но НЕ длинo-зависимыми гардами
|
||||
(см. reflow-инвариантную метрику в §D3: `RegressionGuard`/coverage считают легитимный reflow
|
||||
опущением — инструмент, смещённый в пользу этой же гипотезы, ею мерить нельзя).
|
||||
5. **Упаковка в ВЫХОДНЫХ токенах — самопоправка, не «сошлось».** §A.3 шаг 2 держал первичный бюджет
|
||||
в токенах целевого вендора с прогнозом выхода отдельной проверкой; §B1 переворачивает: первичный
|
||||
бюджет = прогноз ru-выхода (fertility-оценка), оффлайн-токенайзеры уходят в одноразовую
|
||||
калибровку. Это движение К 09 §2/`L2-budget-wrong-unit`, фиксирую как явную поправку.
|
||||
|
||||
**Поправки фактуры §A (вносятся здесь — §A заморожен и не редактируется):**
|
||||
- **[несущая] Провайдер-сет кэша в §A.1.2/§A.4 назван неверно.** «Все четыре провайдера пайплайна» с
|
||||
Anthropic в списке — ошибка: Anthropic в стеке НЕТ (ключей нет, D36.1), а **ZAI/GLM — фактический
|
||||
editor-кандидат и самая дорогая стадия — в списке отсутствует, и его префикс-кэширование НЕ
|
||||
верифицировано**. Верифицированы официальные доки DeepSeek/OpenAI/Gemini (+Anthropic как
|
||||
индустриальный образец breakpoint-механики). Правило двух направлений: ДО опоры warm-then-fan/COGS
|
||||
на editor-стадию — вендор-чек кэша ZAI/GLM (пункт §E.8-бис). Вся кэш-зависимая аргументация
|
||||
(§B3-бис W1, §D-Q2c, §E.1) — условна на этом чеке.
|
||||
- SEGALE: деградация 4k–8k — «у БОЛЬШИНСТВА из семи open-weight моделей», Qwen2.5-72B — явное
|
||||
исключение (стабилен до 4k); §A.1.1 переобобщил.
|
||||
- Разброс chars/token «до ~70%»: несущие числа — КРОСС-вендорные (zh ≈1.0 chars/tok o200k vs
|
||||
≈1.5–1.7 DeepSeek/Qwen vs 0.8–1.8 Gemini); пара «cl100k 2.08×→o200k 1.34×» — внутри-вендорный
|
||||
генерационный пример (≈55%), в §A.2 они склеены.
|
||||
- Raunak (§A.5): формат «сначала перечисли правки» сохраняет выигрыш над ЧЕРНОВИКОМ, но выигрыш
|
||||
МЕНЬШЕ, чем у прямой полной правки (En-Zh CoT COMET 86.43 vs 87.53); «без потери качества» — сильнее
|
||||
вердикта верификатора.
|
||||
- Метки вердиктов в §A: Voita-клейм помечен CONFIRMED — фактический вердикт верификатора OVERSTATED
|
||||
с коррекцией (8.5%→7%, ошибочная ячейка знаменателя; §A уже цитирует СКОРРЕКТИРОВАННЫЕ числа);
|
||||
SB998-клейм — OVERSTATED (no-break только ВНУТРИ абзаца, SB4 рвёт на ParaSep; §A уже говорит
|
||||
«внутри абзаца»). Метка «CONFIRMED по TR29+UCD» относится только к SB9–SB11/STerm.
|
||||
|
||||
### B1. Целевой чанкер (слой 1) — спецификация для Go
|
||||
|
||||
Инварианты: чистая функция входа (никаких time/rand/map-order — контракт `chunker.go:15-22` цел);
|
||||
общность §0.1 (профиль структуры — вход, не приговор); «никогда не резать предложение»; поведение
|
||||
версионируется `chunkerVersion` + снапшот-folded конфиг по образцу `coverageSnap`.
|
||||
|
||||
**B1.1 Конфиг (снапшот-folded, вместо const):**
|
||||
```yaml
|
||||
chunker:
|
||||
strategy: logical # greedy (текущее поведение, байт-совместимый фоллбек) | logical
|
||||
target_output_tokens: 2200 # ЦЕЛЬ в выходных токенах цели (ru), не в символах источника
|
||||
min_output_tokens: 700 # хвост меньше — перебалансировка двух последних чанков
|
||||
hard_max_output_tokens: 3500 # непревышаемый потолок эмиссии (ниже зоны деградации дешёвых моделей)
|
||||
fertility: {cjk_char: 0.75, other_char: 0.25} # src-символ → ru-out-токены; калибруется, см. B1.2
|
||||
```
|
||||
Точечные значения выше — placeholder до кривой §D-Q2 (hard_max=3500 сознательно ВЫШЕ зоны деградации
|
||||
open-weight из §A.1.1 — потолок уточняет Q2, не пресуппозиция); несущее — СХЕМА и единица.
|
||||
Legacy-режим: `strategy: greedy` + бюджет, эквивалентный 1500 src-ток, обязан воспроизводить текущую
|
||||
нарезку байт-в-байт НА УРОВНЕ ЧАНКОВ (golden-инвариант №8 расширить чанкер-фикстурой). Честно про цену:
|
||||
сам ввод chunker-секции в снапшот меняет snapshotID → лендинг = одноразовый `--resnapshot` (полная
|
||||
переоплата in-flight книги, `snapshot.go` это документирует) + сознательный golden re-capture.
|
||||
Примечание по именам: подсекции §B0–§B4 ≠ классы границ B0–B5 (классы — всегда без «§»).
|
||||
|
||||
**B1.2 Бюджет в выходных токенах — детерминированная оценка.** Упаковщик по-прежнему считает
|
||||
классы символов источника (`tokenClassCounts` реюз), но конвертирует их в ПРОГНОЗ выходных ru-токенов:
|
||||
`est_out = f_cjk·cjk + f_other·other`. Коэффициенты фертильности калибруются ОФФЛАЙН одним
|
||||
eval-скриптом на уже существующих 25-глав rerun-данных (`records.json`: source/final пары):
|
||||
оффлайн-токенайзеры уже ВЕНДОРЕНЫ в репо (`eval/tokenizers/*/tokenizer.json`, HuggingFace-формат,
|
||||
грузятся Python-`tokenizers` — `eval/token_calc.py`; ⚠ `deepseek-v4/` пуст — добрать с оф. сайта);
|
||||
tiktoken — только для OpenAI-энкодингов. «Pure-Go-загрузка» — НЕ обещается до вендор-верификации
|
||||
форматов (правило двух направлений); Go-коду нужны только выкалиброванные КОЭФФИЦИЕНТЫ, не токенайзер.
|
||||
Регрессия out-токенов финалов на (cjk, other) источника; коэффициенты — данные конфига
|
||||
per-language-pair (слой 2), пересчёт = громкий resnapshot. Src-оценка остаётся второй величиной с
|
||||
явным инвариантом: min-бюджет чанкера обязан держать чанки НАД `Gates.Coverage.MinChunkChars`
|
||||
(иначе excision-гейт тихо выключается — документированная граница `chunker.go:42-46`); чанк под
|
||||
флором — телеметрия-линт. (`L2-budget-wrong-unit` требует именно этой развязки двух величин.)
|
||||
|
||||
**B1.3 Структурный профиль (шаг 0, per-глава + агрегат книги).** Детерминированные счётчики:
|
||||
медиана предложений/абзац (line-per-sentence детект: ≈1), доля диалоговых абзацев (открыватели
|
||||
「『“«— и т.п.), инвентарь разделителей (строки из орнамент-символов *◇◆■○※*#—═一, ≥2 подряд пустые
|
||||
строки — с поправкой: в ja-вебновелл-конвенции пустые строки = читабельность-шум, сигнал только если
|
||||
их плотность НЕ фоновая), внутриглавные заголовки/номера, отношение размера главы к target.
|
||||
Выход: `StructureProfile{LineSentRatio, DialogueShare, SeparatorLexicon, BlankLineBaseline, …}` —
|
||||
вход детектора границ. Гистерезис: профиль книги = медиана глав; глава отклоняется от книжного
|
||||
режима только при сильном сигнале (анти-флип-флоп, §A.8.5).
|
||||
|
||||
**B1.4 Кандидаты границ (шаг 1).** Каждой позиции-кандидату — класс силы:
|
||||
- **B0**: граница главы (уже есть через ingest); явный разделитель из профиля (орнамент-строка;
|
||||
пустой блок, если blank-line не фоновый шум по профилю).
|
||||
- **B1**: лексиконы сдвига время/место/POV в первых N символах абзаца (данные слоя 2, per-language:
|
||||
次日/翌日/三年后/数日后/一方/却说/再说/こうして/翌朝/Наутро/Тем временем/…); переход диалог-ран → нарратив.
|
||||
- **B2**: TextTiling-долина лексической когезии: скользящие окна по w предложений, косинус
|
||||
мешков символьных биграмм (zh/ja; для en/ru — нижний регистр + лёгкий стем), depth-score долины
|
||||
≥ порога в z-score (μ+kσ по главе). Плюс обрыв цепочки упоминаний сущностей (термы глоссария —
|
||||
Aho-Corasick уже в памяти v2). B2 только РАНЖИРУЕТ кандидатов внутри бюджетного коридора —
|
||||
никогда не «утверждает сцену» (STSS: F1≈37% — на детекцию сцен полагаться нельзя, §A.2).
|
||||
- **B3**: граница абзаца (`splitParagraphs` реюз; в line-per-sentence режиме — границы диалог-ранов,
|
||||
склеенных по профилю).
|
||||
- **B4**: граница предложения (`splitSourceSentences` реюз).
|
||||
- **B5**: внутри предложения — запрещено; предложение > hardMax → аварийный клауза-сплит по ;:,、
|
||||
с флагом `oversized_sentence` в телеметрию.
|
||||
Диалог-констрейнт: разрез между репликой и её атрибуцией и внутри обмена штрафуется надбавкой
|
||||
(русская типографика делает пару «реплика+слова автора» неделимой — §A.6).
|
||||
|
||||
**B1.5 Упаковка (шаг 2) — DP вместо жадности.** Стоимость чанка `[i..j)`:
|
||||
`w_size·sizePenalty(est_out; target, min, hardMax — асимметрично, перебор дороже)` +
|
||||
`w_bound·penalty(класс правой границы: B0=0 < B1 < B2 < B3 < B4)` + `w_dialog·(разрез внутри обмена)`.
|
||||
Кратчайший путь по кандидатам (Кнут-Пласс), O(N·W), W = кандидаты в окне hardMax.
|
||||
**Детерминизм всерьёз:** все стоимости — в МАСШТАБИРОВАННЫХ ЦЕЛЫХ (никаких float в путевых суммах —
|
||||
FMA-контракция Go даёт архитектурно-зависимые результаты, а текущий упаковщик чисто целочисленный);
|
||||
B2-скоры (z-score/косинус) квантуются в целые ДО входа в DP; явный tie-break равных путей (раньший
|
||||
разрез, затем сильнейший класс). Недобор хвоста — ЧЕРЕЗ саму DP-стоимость (undersize-штраф
|
||||
последнего чанка), без отдельного пост-пасса ре-баланса (второй код-путь = второй источник
|
||||
недетерминизма). Жадный `strategy: greedy` остаётся отдельной веткой (байт-совместимость + арм Q1).
|
||||
Веса w_* — конфиг, folded.
|
||||
|
||||
**B1.6 Выход и телеметрия.** `Chunk` расширяется аддитивно (контракт Chapter/ChunkIdx/Text цел):
|
||||
`BoundaryClass` (класс правой границы), `SceneID` (порядковый номер B0/B1-сегмента в главе),
|
||||
`OversizedFlag`. Телеметрия в quality-report (слой 5): распределение классов разрезов
|
||||
(доля B0–B2 vs B3–B4 = наблюдаемое качество нарезки), гистограмма est_out, число аварийных сплитов.
|
||||
|
||||
### B2. Фоллбек-лестница — полный веер (реализация §A.3 шаг 3)
|
||||
|
||||
| Кейс (детектится профилем/размером) | Поведение | Телеметрия |
|
||||
|---|---|---|
|
||||
| глава ≤ target | 1 чанк | — |
|
||||
| глава > target, есть B0/B1 | DP по B0/B1, добор B2/B3 внутри крупных сцен | доля B0/B1-разрезов |
|
||||
| плоский текст (line-per-sentence, сцен-маркеров нет — ранняя арка 蛊真人) | B2-ранжирование у бюджета; долины < порога → DP по B3/B4 (= не хуже жадности) | `weak_boundary` |
|
||||
| мега-абзац > hardMax | B4 внутри абзаца (уже есть: `packSentences`) | — |
|
||||
| мега-предложение > hardMax | клауза-сплит ;:,、 | `oversized_sentence` |
|
||||
| стихи/песни/письма (ран коротких строк без терминаторов, высокая доля B5-невозможных) | блок целиком, не резать; если > hardMax — B3 по строфам | `verse_block` |
|
||||
| эпиграф/авторское примечание/анонс | отдельный класс чанка (не смешивать со сценой) | `paratext` |
|
||||
| смешанные конвенции по главам | профиль per-глава с гистерезисом от книжного | `profile_flip` |
|
||||
| пустые/навигационные главы | как сейчас: не потребляют номер главы (`chunker.go:59-61`) | — |
|
||||
|
||||
### B3. Меж-чанковая когезия — оживление `STMDepth`/`OverlapTokens` (слой 1, концерн claim-2)
|
||||
|
||||
Мёртвые кнобы (`config/pipeline.go:47-48`) замещаются НОВЫМИ явными (`carryover_sentences`,
|
||||
`lookahead_sentences` — не переворачивать единицы старых имён: yaml документирует stm_depth в чанках
|
||||
и overlap_tokens в токенах; старые поля снести — они dead-but-snapshot-live, любая правка и так
|
||||
ре-пинит снапшот):
|
||||
- **Carryover**: хвост предыдущего чанка ГЛАВЫ — последние K предложений ИСТОЧНИКА (реюз
|
||||
`splitSourceSentences`) ∥ последние L предложений его финального ПЕРЕВОДА — **невыровненная**
|
||||
билингвальная пара (⚠ выровненной пары src↔final НЕ существует: редактор легитимно
|
||||
сливает/перестраивает предложения — `chunkrun.go:68-72`; выравнивание появляется только в
|
||||
сегмент-ID-арме §C1). Для L нужен НОВЫЙ версионируемый ru-сегментер (оракульный сплиттер
|
||||
coverage.go — Python-locked, «Do not couple», `chunker.go:24-29`). Target-side важнее src-side
|
||||
(Fernandes/DocRepair, §A.1.3). Прод-значение K=2–3 (DelTA k=3); через B0-границу — 0–1.
|
||||
Деградация: прев-чанк flagged/пуст → src-only carryover (детерминированное правило).
|
||||
**Источник байтов** — сырой текст финального чекпоинта (НЕ `exportNormalize`-проекция: она
|
||||
задекларирована ephemeral/no-wire-touch, `chunkrun.go:224`; потащить её на wire = невент-
|
||||
версионированный трансформ начинает менять request_hash → тихая переоплата класса D5.2).
|
||||
Любой трансформ на carryover-пути (хвосторез, сегментер) версионируется в снапшоте
|
||||
(`carryoverVersion`, дисциплина coverageSnap).
|
||||
- **Lookahead**: первые M предложений СЛЕДУЮЩЕГО чанка ТОЙ ЖЕ ГЛАВЫ (через границу главы M=0 —
|
||||
глава = сцен-ресет, дисциплина sticky), только источник — статически известен чанкеру, не зависит
|
||||
от выходов → параллелизм-безопасен. Закрывает катафору/zh zero-anaphora вперёд (единственный
|
||||
механизм; exp14 A-ref-next не гонялся — Q3-арм). **Гард утечки:** модель может ПЕРЕВЕСТИ
|
||||
lookahead (верхняя граница len_ratio у coverage-гейта не проверяется — `coverage.go` использует
|
||||
только нижнюю) → детерминированный шов-дедуп-детектор в §D-метрики и в прод-телеметрию.
|
||||
- **Структурный стейт сцены (не свободная проза!)**: слоты, собираемые ДЕТЕРМИНИРОВАННО:
|
||||
активные сущности (sticky ids памяти v2 + их dst-формы + пол персонажа — новое поле сида),
|
||||
класс/ID сцены от чанкера, открытый диалог-ран (кто говорил последним, если детектимо по
|
||||
атрибуции). Свободный LLM-running-summary в прод НЕ закладывать: инкрементальный пересказ
|
||||
удваивает omission (BooookScore) и дрейфует без перегрунтовки (§A.4.3); LLM-стейт = Ф2-аннотатор.
|
||||
- **Порядок промта (кэш-закон верифицированных провайдеров — DeepSeek/OpenAI/Gemini; для ZAI/GLM
|
||||
кэш НЕ верифицирован, см. §B0-поправку и §E.8-бис):** [система+мандаты] → [глоссарий, сорт-ключи
|
||||
детерминированы] → [стейт сцены] → [carryover] → [lookahead] → [чанк]. Инъекция — сообщениями:
|
||||
request_hash-довод ВЕРЕН (инъекция = сообщение, хешируется автоматически — resume-детерминизм),
|
||||
но честно про объём работ: реестр `roleInjectionRenderers` сегодня принимает только
|
||||
`[]pickedEntry` и предвычисляется из memSel ДО стадий, `MessagesWithInjection` несёт ОДИН
|
||||
инъекционный слот, а prev-final/next-chunk в `translateChunk` не заводятся — это
|
||||
сигнатурная проводка bookrun→translateChunk→runStage→render (контекст-структура + упорядоченный
|
||||
список блоков), а не «данные + один рендерер».
|
||||
- **Деньги/детерминизм:** в снапшот фолдятся ТОЛЬКО КНОБЫ (K/L/M/веса/версии трансформов —
|
||||
contextSnap-паттерн); БАЙТЫ carryover в снапшот не фолдятся и не могут (снапшот считается ДО
|
||||
цикла, `snapshot.go:190` прямо исключает STM: «пересобирается из чекпоинтов») — байты входят в
|
||||
детерминизм через messages → request_hash и на resume пересобираются из чекпоинтов
|
||||
(`chunk_status.FinalHash → GetCheckpoint`). Ретрай чанка байт-идентичен (постфактум-приписки
|
||||
запрещены — ломают префикс-кэш); ретрай чанка N не меняет вход чанков ≠N+1.
|
||||
- **⚠ Конфликт с параллелизмом (V4-п1/H9), фиксирую явно:** carryover со стороны ПЕРЕВОДА создаёт
|
||||
последовательную цепочку внутри главы. Варианты: (а) параллелить ГЛАВЫ, чанки главы — конвейером
|
||||
(кэш-warm бонус: warm-then-fan); (б) carryover src-only → полный параллелизм, слабее когезия;
|
||||
(в) двухволновый прогон (волна 1 — черновики параллельно, волна 2 — редактура с carryover по
|
||||
цепочке). Решение — владельцу после Q3 (сколько когезии реально покупает target-side carryover).
|
||||
|
||||
### B3-бис. Волновая архитектура — параллелизм без потери когезии (вводная владельца, 2026-07-16)
|
||||
|
||||
Владелец зафиксировал требование (V4-п1/H9 из открытой идеи стало вводной): черновики слать
|
||||
ПАРАЛЛЕЛЬНО чанками; из черновика формировать единый банк памяти; затем редактор чинит термины и
|
||||
точечно поднимает художественность. Разбор «чем жертвуем» показывает, что дихотомия
|
||||
«последовательный vs параллельный» — ложная, как и «крупный vs мелкий чанк» (§A.1): по-настоящему
|
||||
несёт качество последовательность ВОЛН, а не чанков. Ключ — расщепление контекста:
|
||||
|
||||
- **Source-side контекст параллелизм НЕ ограничивает:** исходник статичен и известен целиком до
|
||||
первого вызова → src-carryover (хвост предыдущего чанка-источника), lookahead (катафора — даже
|
||||
ЛУЧШЕ, чем в последовательном конвейере: вперёд смотреть можно всегда), сцен-стейт от чанкера и
|
||||
глоссарий-сид вкладываются в каждый параллельный запрос волны 1 бесплатно. Анафору/дейксис модель
|
||||
черновика разрешает по ИСХОДНИКУ (якорь в 1–3 предложениях — Voita/CXMI, §A.1.3).
|
||||
- **Target-side контекст нужен РЕДАКТОРУ, не переводчику** (D30.2-сплит: дискурс — работа редактора),
|
||||
а к волне редактуры черновики ВСЕЙ книги уже существуют → редактор получает соседей-черновиков
|
||||
read-only В ОБЕ СТОРОНЫ без какой-либо последовательности.
|
||||
|
||||
**Волны:**
|
||||
- **W0 (детерминированная, $0):** ingest → чанкер B1 (профиль, DP-границы) → src-контекст-пакеты.
|
||||
- **W1 (черновики, полный параллелизм):** статичный префикс + src-carryover/lookahead + чанк;
|
||||
кэш: warm-then-fan (первый запрос греет префикс, фан-аут после первого токена ответа — иначе
|
||||
параллельные запросы платят full-price input; при DeepSeek-хите ~1–2% цены — копейки, но дисциплина).
|
||||
- **W1.5 (консолидация банка, между волнами = снапшот-граница, НЕ mid-run-append):** глобальный
|
||||
майнинг термин-кандидатов по ВСЕМ черновикам + реконсиляция алиас-кластеров/пола + подпись
|
||||
владельца на спорных (дисциплина сида цела). Глобальная пост-хок консолидация КАЧЕСТВЕННО лучше
|
||||
онлайн-замка первого перевода: замок награждает консистентность-с-первым, даже плохим
|
||||
(LTCR-отравление, §A.4.2), а иерархическая сборка состояния измеренно бьёт инкрементальную
|
||||
(BooookScore, §A.4.3). Это же — V4-п4 glossary-auto-build.
|
||||
- **W2 (редактура, параллельна):** узкие мандаты §C + банк-enforce + draft-соседи как carryover.
|
||||
- **W2.5 (опционально, по Q5):** «швейный» микро-пасс ТОЛЬКО по границам чанков — читает зону стыка
|
||||
двух отредактированных чанков, эмитит диффы (blast-radius = шов); параллелен по швам.
|
||||
- **W3 (reflow-план по сценам §C1.3):** параллелен по главам/сценам.
|
||||
|
||||
**Цена параллелизма (что реально теряем):** (а) термин-разнобой ВНУТРИ черновиков — чинится W1.5+W2
|
||||
(в вебновелл-домене сущности/термины = 62.5% document-level ошибок, все банко-адресуемы — BWB);
|
||||
(б) швы между независимо отредактированными чанками — W2.5/Q2c; (в) carryover от
|
||||
уже-ОТРЕДАКТИРОВАННОГО соседа (последовательный конвейер) vs от ЧЕРНОВИКА соседа (волна) — дельта
|
||||
неизвестна и ИЗМЕРИМА: расщеплённый Q3-арм (§D). **Что покупаем:** wall-clock (дни → часы на книгу
|
||||
в тысячи чанков); **ретрай без каскада** — в последовательной схеме с target-carryover ретрай чанка
|
||||
меняет вход всех последующих (каскадная переоплата, боль снапшота), в волновой ретрай изолирован;
|
||||
глобальный банк vs локальный замок. Следствие для B3: carryover проектируется в ТРЁХ режимах
|
||||
(src-only | draft-сосед | final-сосед), режим — конфиг волны; §E.1 снимается, вопрос владельцу
|
||||
переформулирован (§E.1-новый).
|
||||
|
||||
### B4. Что сознательно НЕ строить (анти-скоуп, из верифицированной фактуры)
|
||||
|
||||
1. **Семантик-чанкинг модель-вызовами / LLM-сегментация (LumberChunker-класс)** — retrieval-only
|
||||
выгоды, цена и недетерминизм; владелец это и запретил, литература подтверждает (§A.2).
|
||||
2. **ML-классификатор сцен** — F1≈24–37% на самом задокументированном корпусе; хуже честной
|
||||
лестницы с DP (§A.2).
|
||||
3. **Эмбеддинг-границы** — GraphSeg-урок (хуже рандома на естественных документах) + зависимость
|
||||
от модели в детерминированном контуре.
|
||||
4. **Свободный LLM-running-summary в прод-контуре** — см. B3; до Ф2 стейт только детерминированный.
|
||||
5. **Симметричный RAG-оверлап (дублирование текста в двух чанках)** — недетерминированный дедуп на
|
||||
склейке; вместо него carryover/lookahead read-only (перевод каждого предложения принадлежит ровно
|
||||
одному чанку — лосслесс-тайлинг `chunker.go:123-124` цел).
|
||||
|
||||
---
|
||||
|
||||
## §C — Контракт переводчик/редактор (концерн 1; для эмпирики, не прод-приговор)
|
||||
|
||||
### C1. Целевой контракт ролей
|
||||
|
||||
- **Переводчик = верный СТРУКТУРНЫЙ подстрочник** (формализация текущего поведения, не смена):
|
||||
1:1 к предложениям источника, зеркалит построчную структуру (это НЕ баг — это выравнивание:
|
||||
делает omission детектируемым кодом и диффы адресуемыми), reflow НЕ делает. Инертный reflow-однострочник
|
||||
из translator.md убрать / заменить явным «подстрочник, НЕ переверстывай» (ледджер
|
||||
`L1-split-intended-not-accident`). Локус «reflow у переводчика» из Q4-вопроса промта закрыт так:
|
||||
слабая форма (однострочник) эмпирически инертна (research/18 §A.2, exp14) — не арм; сильная форма
|
||||
(дискурс-решения в черновике) тестируется Q4a «сильный переводчик». Опция «сегмент-маркеры»
|
||||
(нумерация предложений в черновике) — суб-фактор арма Q4b (Q4b±маркеры), не пресуппозиция:
|
||||
маркеры делают адресацию правок тривиальной, но меняют wire-формат (санитайзеру их снимать).
|
||||
- **Редактор = узкие проходы вместо 4-мандатной full-regen:**
|
||||
1. **Fidelity-проход (диффы):** src+draft → список операций «якорь→замена» ТОЛЬКО про смысл
|
||||
(полярность/числа/ранги/опущения/термины). Первоклассный выход — «правок нет» (WMT19 en→ru:
|
||||
ни одна APE-система не побила do-nothing на сильном черновике; LLM-редакторы правят даже
|
||||
корректный вход — гейт снаружи обязателен).
|
||||
2. **Стиль-проход (диффы или full-regen — арм):** де-кальки, живой русский; глоссарий-констрейнты
|
||||
как сейчас.
|
||||
3. **Reflow-проход = широкое чтение / узкая эмиссия:** видит СЦЕНУ/главу (все чанки read-only),
|
||||
эмитит ПЛАН переверстки — группировку сегментов в абзацы + типографику диалога, применяет КОД.
|
||||
План структурно omission-safe: валидатор требует «каждый сегмент использован ровно один раз» —
|
||||
перестановка/слияние возможны, потеря НЕВОЗМОЖНА (в отличие от full-regen, где полнота
|
||||
держится на честности модели). Это прямой тест развязки §A.1: выгода «крупного чанка» по
|
||||
абзацам должна воспроизводиться крупным ОКНОМ при мелкой эмиссии.
|
||||
- **Гейты между проходами** — уже построенное: coverage (переводчик), RegressionGuard
|
||||
(длина/числа), санитайзер, glossary post-check; диспозиция D2 «первый флаг стопит чанк» цела.
|
||||
|
||||
### C2. Дифф-протокол (спека для эмпирики)
|
||||
|
||||
- **Формат: anchored search/replace-блоки** (самый надёжно эмитируемый: Diff-XYZ EM 0.68–0.95;
|
||||
mid-tier 91–98% комплаенса на aider; оба вендора тренируют на context-anchored форматах).
|
||||
НИКАКИХ номеров строк/сегментов в якоре (если нет сегмент-маркеров арма Q4).
|
||||
- **Go-apply толерантный:** якорь ищется с нормализацией пробелов/пунктуационных вариантов;
|
||||
неоднозначный якорь (≥2 совпадений) → reject операции (не тихое применение первого); якорь не
|
||||
найден → reject; reject-rate — телеметрия. (aider: отключение толерантного apply = 9× ошибок.)
|
||||
- **Петля**: малформед/reject → 1 регенерация → далее операция ОТБРАСЫВАЕТСЯ (черновик остаётся) —
|
||||
blast-radius одной правки, а не чанка. Формат-комплаенс per-model — метрика Q4; модель ниже
|
||||
~90% комплаенса на русской прозе → full-regen-фоллбек с гардами (весь формат-корпус — код,
|
||||
на прозе НЕ мерен: это гипотеза для эмпирики, не факт).
|
||||
- **Cache-друг**: черновик в промте = стабильный префикс; правки — компактный суффикс-выход
|
||||
(выходные токены — доминанта COGS: дифф-редактор радикально дешевле full-regen по out-токенам).
|
||||
|
||||
### C3. Порядок и do-nothing дисциплина
|
||||
|
||||
Порядок проходов: fidelity → style → reflow (reflow последним: он видит уже верный текст; его план
|
||||
не трогает содержимое сегментов). Каждый редакторский арм в эмпирике меряется ПРОТИВ do-nothing
|
||||
(экспорт черновика как есть). Уточнение: exp12 draft-only арм ($0) ставился и судился — не ставилось
|
||||
другое: КАЖДЫЙ editor-арм против do-nothing на пре-регистрированных метриках (exp14 этого не имел);
|
||||
APE-фактура говорит, что планка нетривиально высокая. «Сначала перечисли правки, потом применяй»
|
||||
(Raunak: −¼–⅓ объёма правок с сохранением выигрыша над черновиком, но меньшим, чем у прямой полной
|
||||
правки — коррекция верификатора) — дисциплина промта fidelity/style-проходов.
|
||||
|
||||
### C4. Арм «сильный переводчик» (Q4, чистое поле)
|
||||
|
||||
Единственная ячейка без датапоинтов (полигон-синк факт 1; ледджер
|
||||
`L1-translator-structure-arm-never-tested`).
|
||||
Гипотеза: черновик, уже несущий дискурс-решения (эксплицитация zh-нулевых местоимений, верная
|
||||
полярность), сжимает мандат редактора до стиля+реflow → меньше инверсий (корень D34.3 — конкуренция
|
||||
мандатов). Кандидаты арма: deepseek-v4-pro / mistral (оба чинят a1-класс как редакторы, exp14b) /
|
||||
gpt-5.4 (диагностика потолка); слаги — live-фактчек `/models` перед прогоном (гардрейл).
|
||||
|
||||
---
|
||||
|
||||
## §D — ПРЕ-РЕГИСТРИРОВАННЫЙ дизайн полигон-эмпирики (исполняет полигон-сессия, отдельный промт)
|
||||
|
||||
> Этот §D — дизайн-оф-рекорд; полигон при исполнении фризит его коммитом ДО первого платного вызова
|
||||
> и НЕ меняет пост-фактум. **Фриз пинит НЕ только слаги/цены/капы, но и: коммит-хеш бэкенда,
|
||||
> хеш сида-снапшота, хеши промт-файлов (translator/editor v3), конфиги инъекции** — трек A
|
||||
> параллельно мутирует pipeline-код (грязное дерево на 16.07), и «поплывший» A0 испортил бы все
|
||||
> контрасты; любое изменение после первого платного вызова = новый experiment-ID. Мандат самопроверки
|
||||
> (CLAUDE.md): ревью ИСПОЛНЕНИЕМ своего кода + сформированных запросов + результатов — в каждый скрипт.
|
||||
|
||||
### D0. Материал: структурно-разнообразный корпус (инвариант общности §0.1)
|
||||
|
||||
Срезы (билдеры в репо: `gu_corpus_build.py`, `ja_corpus_build.py`, `en_corpus_build.py`,
|
||||
`jpm_corpus_build.py`, `webnovel_slice.py`):
|
||||
- **S1 плоский CJK** — поздние главы 蛊真人 вне уже-юзанного раннего среза (line-per-sentence,
|
||||
мало маркеров) — точка «фоллбек-режим».
|
||||
- **S2 сцен-маркированный zh-вебновелл** — срез с реальными разделителями/сдвигами сцены (подбор
|
||||
билдером по плотности маркеров; гейт «вне претрейна» — свежие главы) — точка, где Q1 вообще
|
||||
может дифференцировать.
|
||||
- **S3 ja-ранобэ** — line-per-utterance диалоги, безатрибуционные реплики (нагрузка на carryover
|
||||
и пол/говорящего).
|
||||
- **S4 длинно-абзацный европейский (en)** — контроль общности (профиль обязан переключить режим).
|
||||
Объём: 8–12 глав на несущий срез (S1/S2), 3–4 на контрольные (S3/S4). **Скоуп per-срез (честно про
|
||||
слой 2):** платные армы перевода — только S1/S2 (zh→ru — единственные прод-промты; D39: контент
|
||||
слоя 2 = только zh→ru); S3/S4 — ЧАНКЕР-профилирование и нарезка ($0, детерминированная валидация
|
||||
общности §0.1); платить за ja/en-переводы риг-промтами = мерить не прод-контракт, не делаем.
|
||||
Претрейн-каветы: S1 (蛊真人) — широко скрейпленная книга, претрейн-гейт НЕ проходит — S1 валиден
|
||||
для нарезки/структуры и внутрипарных контрастов, «вне претрейна» несёт S2. До прогона: структурный
|
||||
профиль каждого среза печатается в отчёт (проверка, что срез РЕАЛЬНО задействует рычаг — иначе
|
||||
снова неинформативный null, урок полигон-синка).
|
||||
|
||||
### D1. Маркированный трап-набор (закрывает §D-1 аудита «locus когезии не размечен»)
|
||||
|
||||
Типы (из верифицированной таксономии Voita + zh-специфика + русская целевая сторона):
|
||||
| Тип | Что ловит | Пример конструкции | Кто должен чинить |
|
||||
|---|---|---|---|
|
||||
| T-ana | анафора назад через границу (zh zero-subject, антецедент в чанке i, реализация в i+1) | 他/она-эксплицитация | carryover (Q3) |
|
||||
| T-cat | катафора вперёд (референт в i+1) | «Это был…» → имя в следующем чанке | lookahead (Q3) |
|
||||
| T-ell | эллипсис/восстановление сказуемого через границу | zh-эллипсис глагола | carryover |
|
||||
| T-ent | сущность-через-границу (термин/титул введён в i, повторён в i+1) | 四代族长-класс | глоссарий+carryover |
|
||||
| T-gen | пол говорящего/деятеля через границу (ru прошедшее время) | «пошёл/пошла» | стейт (пол в сиде) |
|
||||
| T-tense | тенс-консистентность внутри сцены через разрез | нарративное время | сцен-граница (Q1) |
|
||||
| T-reg | смена регистра/голоса на сцене | вежливость/просторечие | стейт+carryover |
|
||||
| T-inv (контроль) | внутри-чанк инверсии a1-класса (двойное отрицание, 没有一个不知道) | exp14b-батарея реюз | editor-модель (НЕ нарезка) |
|
||||
**Дисциплина маркировки:**
|
||||
- Кандидаты добываются LLM-майнингом + ручной отбор; **майнер-модель фиксируется в пре-реге и
|
||||
ИСКЛЮЧАЕТСЯ из судейского пула** (и не совпадает семьёй с арм-моделями) — иначе трапы преднагружены.
|
||||
- **Стратификация по дистанции антецедента** (публикуется per-трап): квота X трапов в пределах
|
||||
K=3 предложений (зона carryover) и Y трапов ДАЛЬШЕ K (зона, которую чинит только окно/Ф2) —
|
||||
без неё майнинг естественно наберёт короткие зависимости, и Q3a «выиграет» по построению,
|
||||
а Q2c-специфичные длинные — недосэмплируются.
|
||||
- **Минимальный N на несущий тип: ≥20** (T-ana/T-ent/T-tense; остальные ≥10); недобор → домайнить
|
||||
главы до квоты, иначе тип помечается «Q недоказуем a priori» ДО платных вызовов (не после).
|
||||
- **Общий знаменатель контраста (анти-null-игра):** трапы определяются как пересекающие границу
|
||||
В ЯКОРЕ A0; в ОБОИХ армах контраста скорится ОДИН И ТОТ ЖЕ набор. Пересёк/не пересёк границу в
|
||||
арме — записываемая КОВАРИАТА (она и раскладывает «починено сдвигом границы» vs «починено
|
||||
механизмом»), НИКОГДА не фильтр включения: иначе Q1/Q2a-арм теряет кредит ровно за те трапы,
|
||||
которые он чинит переносом границы (встроенный ложный null), а армы становятся несравнимы.
|
||||
Исключаются только трапы, не пересекающие границу НИ в одном арме контраста.
|
||||
- Ожидаемое поведение каждого трапа записано до прогона (span + правильный/неправильный исходы).
|
||||
|
||||
### D2. Армы — целевые 2-арм контрасты к общему якорю (НЕ факториал)
|
||||
|
||||
**Якорь A0:** прод-кандидат post-D38.5: flash `v1-reflow` → glm-5 `v3` (P1a-дискурс+чэнъюй),
|
||||
greedy-1500, без когезии; RegressionGuard ON; сид reseed-промоутнутый. **На несущем срезе S2 якорь
|
||||
генерится ДВАЖДЫ** (temp>0): само-расхождение A0↔A0′ = floor шума генерации, и любой Q-эффект
|
||||
меньше этого floor не интерпретируется. **Декларация анти-сходимости:** все контрасты делят один
|
||||
якорь → их «победы» коррелированы и НЕ суммируются в нарратив «N сигналов сходятся» (D32.4);
|
||||
повторы судей давят только судейский шум, НЕ шум генерации якоря.
|
||||
|
||||
| Q | Контраст (одна переменная) | Первичная метрика (ОДНА; остальное вторично) | Что разрешает |
|
||||
|---|---|---|---|
|
||||
| **Q1** | A0 vs **logical-граница** (§B1.4/B1.5-DP); **size-match:** DP-бюджет подгоняется так, чтобы распределение est_out совпало с фактическим A0 (±10% по среднему; оба распределения — в пре-ран профиль), иначе класс границы конфаундится размером | T-tense+T-ana точность на S2 (общий знаменатель) | чинит ли ЛОГИЧЕСКАЯ граница когезию (претензия-2), или граница ≪ когезии |
|
||||
| **Q2a** | A0 vs **edit=глава**: draft-стадия ПРИКОЛОЧЕНА к A0-нарезке (greedy-1500), крупнеет ТОЛЬКО единица эмиссии редактора (⚠ exp14-sizecurve ресайзил draft+edit+окно вместе — реплицировать нельзя, атрибуция потеряется; суб-арм «draft тоже глава» — опционально при бюджете) | retry-adjusted cost-of-pass при reflow-инвариантном omission (см. §D3) не хуже A0 | сторону exp14: «дешевле и лучше» — выживает ли после omission/retry-поправки |
|
||||
| **Q2b** | реюз sizecurve-артефактов (800/1600/3200/whole, ch17/13) + omission-скоринг существующих выходов ($0 генерации). **Скоуп: ТОЛЬКО ре-атрибуция кривой exp14** («сколько дешевизны = тихие потери») — промт там до-v3, 2 главы, greedy; сегменты с записанными err-фолбэками исключить (`sizecurve_costs.jsonl`). Ратифицировать/опровергать «edit=глава» для v3-пайплайна Q2b НЕ может — только Q2a | reflow-инвариантный omission per size | дешёвая проверка §B0.4 |
|
||||
| **Q2c** | A0 vs **широкое-чтение/узкая-эмиссия** (эмиссия=чанк, окно=сцена/глава read-only). ⚠ Кэш-условность: editor=glm/ZAI, его префикс-кэш НЕ верифицирован (§B0) — пре-рег обязан вендор-чекнуть; стоимость репортить as-billed И cache-normalized, дисциплина вызовов warm-then-sequential | T-ana+T-tense точность (общий знаменатель с Q2a) при out-токенах ≈ A0 | РАЗВЯЗКА §A.1: воспроизводится ли выгода крупного «чанка» одним окном без крупной эмиссии |
|
||||
| **Q3a** | A0 vs **+carryover (K=3)** — ТРИ режима: src-only / **draft-сосед** / final-сосед. Стейт сцены — ОТДЕЛЬНЫЙ суб-арм Q3a′ (carryover+стейт), атрибуция по типам: carryover не чинит T-gen, стейт не чинит T-ell | T-ana+T-ell точность per режим (Q3a′: T-gen/T-reg) | клейм research/18 Ось-4 + **цена параллелизма** (дельта draft↔final = что теряет волновая модель B3-бис; дельта src↔draft = что даёт target-side) |
|
||||
| **Q3b** | A0 vs **+lookahead M=2** (src-only, параллелизм-безопасен; шов-дедуп-гард включён) | T-cat точность (A-ref-next — пустая ячейка exp14) | нужна ли катафора-ветка |
|
||||
| **Q5** | параллельно-отредактированные стыки vs те же стыки после **швейного микро-пасса** (W2.5, диффы по зоне шва) | шов-дефект-рейт (T-tense/T-reg на швах) | нужен ли W2.5 в волновой модели, или Q2c-окно закрывает швы дешевле |
|
||||
| **Q4a** | A0 vs **сильный переводчик** (draft=deepseek-pro или mistral, editor тот же) + **суб-арм strong-draft+do-nothing** (иначе glm-редактор пере-ломает то, что черновик починил — T-inv по D-логу editor-модельное свойство, ложный null по построению) | fidelity-трапы ЧЕРНОВИКА до редактора (span) | чистое поле «структура у переводчика» |
|
||||
| **Q4b** | A0 vs **diff-based fidelity+style редактор** (§C2; суб-фактор ±сегмент-маркеры) | trap-точность (T-inv) fidelity-first при формат-комплаенсе ≥90% (иначе арм признаётся неисполнимым) | жизнеспособность диффов на русской прозе |
|
||||
| **Q4c** | A0 vs **reflow-план отдельным пассом** (§C1.3) | KPI абзацев (mean_spp) при omission-инварианте (=0 структурно — проверить валидатором) | где живёт reflow |
|
||||
| **Q0** | A0 vs **do-nothing** (экспорт черновика) | эквивалентность-тест (TOST-стиль) с пре-рег маржой M на trap-точности и KPI: «A0−do-nothing < M» — НЕ «в пределах шума» (не-значимость ≠ эквивалентность) | нижняя планка редактуры (APE-урок); обязателен |
|
||||
Порядок исполнения: Q2b (бесплатно, ре-атрибуция) → Q1+Q3 (несущие, S2-срез) → Q2a/Q2c → Q4.
|
||||
Каждый Q — стоп-гейт: полигон вправе остановиться при исчерпании бюджета, пре-рег фиксирует
|
||||
приоритет; НО стоп после Q2b НЕ закрывает центральный конфликт (Q2b — ре-атрибуция, не вердикт).
|
||||
|
||||
### D3. Метрики и агрегация (methodology-guard D32.4 + внешняя методология)
|
||||
|
||||
- **Reflow-инвариантный omission (ГЛАВНЫЙ omission-инструмент, пре-регистрируется и валидируется
|
||||
ДО скоринга армов):** длинo-зависимые гарды (`RegressionGuard` длина-коллапс, coverage-соотношения)
|
||||
СМЕЩЕНЫ против крупных чанков — editor.md явно разрешает слияние предложений/абзацев, и объём
|
||||
reflow растёт с размером → они считают легитимный reflow «опущением», фабрикуя гипотезу B0.4.
|
||||
Вместо них: по КАЖДОМУ предложению источника — присутствие его семантических атомов (числа,
|
||||
сущности/глоссарий-хиты, полярность отрицания) ГДЕ УГОДНО в целевом чанке. Метрика один раз
|
||||
валидируется на вручную вычитанном whole-chapter выходе, потом скорит армы.
|
||||
- **Детерминированные (код, $0):** mean_spp / доля 1-предложенческих абзацев / диалог-тире /
|
||||
CJK-утечка / glossary-консистентность (LTCR-стиль по сиду) / доля разрезов по классам границ /
|
||||
шов-дедуп-детектор (lookahead-армы) / **позиционный градиент ВНУТРИ арма**: детерминированные
|
||||
флаги (атом-omission, число-дрейф) по относительной позиции в чанке (кросс-арм сравнение хвостов
|
||||
некорректно — разные абсолютные позиции; «качество» головы/хвоста — судейское, не $0).
|
||||
- **Карта независимости сигналов (пропущенный D32.4-гард — тот самый, на котором горели дважды):**
|
||||
пре-регистрируется граф «метрика→драйвер»; метрики с общим драйвером (длина выхода: out-токены,
|
||||
mean_spp, длино-гарды) считаются ОДНИМ сигналом в любом мульти-сигнальном выводе; вывод
|
||||
«сигналы сходятся» требует ≥1 длинo-независимого сигнала (trap-точность, span-верность).
|
||||
- **Trap-скоринг:** span-цитирующие судьи ≥2 кросс-семейных (не из семьи армовой модели И не
|
||||
семья майнера трапов), temp 0, каждый пейр в ОБОИХ порядках; повторы: 6 голосов, при расколе
|
||||
≤4:2 — добор до 10 (пре-рег правило эскалации; ослабление против §A.7-нормы «~10» — бюджетная
|
||||
поправка, фиксируется явно), leave-one-judge-out, катастроф-скрин К ПОБЕДИТЕЛЮ тоже;
|
||||
fidelity-first агрегация; никакого pooled-style-взвешивания.
|
||||
- **Стоимость:** cost-of-pass = вся цена арма (ретраи+гейты+кэш-хиты раздельно в usage) / принятые
|
||||
главы; ретраи и кэш-статистика репортятся отдельно; per-call predicted-cost кап ДО каждого вызова.
|
||||
- **Агрегация:** ПАРНЫЕ по-главные разности арм−якорь ВНУТРИ среза; кластер-робастные SE по книге
|
||||
НЕ считаются (несущий срез ≈ одна книга = 1 кластер, оценка не определена) — вместо этого
|
||||
генерализация на «любую книгу» честно декларируется ограничением, закрываемым S1–S4-разнообразием;
|
||||
K>1 судейских повторов = дешёвый множитель мощности (армы родственные); мощность честно: на 8–12
|
||||
главах разрешимы только средние/крупные эффекты — потому первичны ТРАПЫ (высокосигнальные,
|
||||
размеченные, N≥20 на несущий тип), не holistic-скаляры. Один первичный контраст на Q; остальное —
|
||||
Holm-Bonferroni.
|
||||
- **Слепота владельца:** финалисты — слепые пакеты (как exp14b h2h), метки перемешаны.
|
||||
**Человеческий эндпоинт — гейтящий:** метрики НОМИНИРУЮТ арм в прод-кандидаты, финальное решение
|
||||
— слепое чтение владельца (планка 2 претензий, D35); ни один арм не ратифицируется в дефолт
|
||||
только по метрикам.
|
||||
|
||||
### D4. Бюджет и реюз
|
||||
|
||||
Реюз $0: sizecurve-выходы (`exp14/sizecurve/*`), A-ref-prev/both, `material.json→trap_chunks`,
|
||||
exp14b-батарея a/b/c/d (T-inv), 25-глав rerun (`records.json`) для калибровки фертильности B1.2.
|
||||
Новые траты: генерация армов на S1/S2 (дешёвые модели: ~$0.01–0.03/глава-арм) + судьи (доминанта;
|
||||
бюджет судей ПЕРЕСЧИТЫВАЕТСЯ в пре-реге из trap-N × повторы × 2 порядка × ≥2 судей, не наоборот) —
|
||||
грубая оценка всего пакета **$8–15** в рамках ключей D36.1 (~$9/ключ, **кроме Gemini ~€2.6** —
|
||||
аддитивный thinking-биллинг; судейские семьи выбирать с учётом этого); точные капы полигон фиксирует
|
||||
в пре-реге с live-ценами. DeepSeek: кэш-hit ~1–2% цены miss — последовательный прогон чанков с общим
|
||||
префиксом почти обнуляет input-COGS (проверить live-цены; для ZAI/GLM кэш не верифицирован — §E.8-бис).
|
||||
|
||||
### D5. Дерево решений (пре-рег)
|
||||
|
||||
Правило чтения: у каждого Q — ровно одна первичная метрика (таблица §D2), порог и направление
|
||||
фиксируются в пре-реге числом; ниже — ветвление по первичным метрикам, вторичные только объясняют.
|
||||
- **Q2a/Q2c:** Q2a-первичка (cost-of-pass при omission-инварианте) лучше A0 И Q2c НЕ воспроизводит
|
||||
выгоду окном → edit=глава легитимен (§A.8.1). Q2c воспроизводит (его trap-первичка ≥ Q2a при
|
||||
меньшей эмиссии) → развязка «мелкая эмиссия + широкое окно». Reflow-инвариантный omission растёт
|
||||
с размером → exp14-кривая переатрибутируется, мелкая эмиссия + когезия механизмом.
|
||||
- **Q1:** первичка (T-tense+T-ana на общем знаменателе, S2) сдвиг ≥ пре-рег порога → строить
|
||||
§B1.4/B1.5-DP; null на S2 (не только на плоском S1!) → граница вторична, приоритет когезии (Q3).
|
||||
- **Q3a/Q3b:** знаменатель = кросс-граничные трапы, которые A0 ПРОВАЛИВАЕТ; carryover чинит ≥50%
|
||||
этого знаменателя → оживление carryover ратифицируется (режим — по дельте src/draft/final и
|
||||
решению владельца §E.1); null при верифицированно пересекающих → когезия требует окна (Q2c-форма)
|
||||
или Ф2.
|
||||
- **Q4a:** суб-арм strong-draft+do-nothing судится по fidelity-трапам ЧЕРНОВИКА: сильный черновик
|
||||
чинит ≥ пре-рег доли T-inv, которые flash-draft валит, при COGS ≤ пре-рег потолка → арм
|
||||
«структура у переводчика» в прод-кандидаты (полный Q4a-пайплайн тогда меряет, не ломает ли
|
||||
редактор починенное).
|
||||
- **Q4b:** формат-комплаенс <90% ИЛИ fidelity-first trap-точность хуже full-regen → диффы
|
||||
откладываются (D-лог закрывает NEVER_CLOSED D21.4/D21.10 явно, не молча); ≥90% и атом-omission=0
|
||||
→ дифф-редактор в прод-кандидаты.
|
||||
- **Q4c:** mean_spp ≥ A0 И атом-omission=0 (валидатор плана) при COGS ≤ A0×1.3 → reflow живёт
|
||||
отдельным пассом; иначе reflow остаётся в editor-промпте (v3 как есть).
|
||||
- **Q0:** эквивалентность (TOST, маржа M из пре-рега) A0↔do-nothing на первичках → мандаты
|
||||
редактора на этих осях пересматриваются (APE-урок в действии); НЕ-отвержение без эквивалентности
|
||||
= «данных мало», не «редактор бесполезен».
|
||||
- **Финал любой ветки:** прод-кандидат → слепое чтение владельца (гейтящий эндпоинт, §D3).
|
||||
|
||||
---
|
||||
|
||||
## §E — Открытые вопросы (владельцу / бэкенду / оркестратору)
|
||||
|
||||
**Владельцу:**
|
||||
1. **[переформулирован после вводной 16.07 — волновая модель принята за рабочую]** Волновая
|
||||
архитектура B3-бис отвечает на параллелизм; остаточный вопрос: если Q3a покажет заметную дельту
|
||||
«final-сосед > draft-сосед» (цена параллелизма ненулевая) — готовы ли принять гибрид «чанки главы
|
||||
конвейером, главы параллельно» для финального прохода, или скорость приоритетна безусловно?
|
||||
Плюс: W1.5-консолидация банка предполагает вашу подпись на спорных термах МЕЖДУ волнами — ок ли
|
||||
такой человеческий гейт в середине прогона книги (UX ридер-дерева)?
|
||||
2. **Пол персонажа в сиде** — новое первоклассное поле схемы глоссария (T-gen-класс дефектов —
|
||||
самый видимый в ru). Расширение схемы = ваша подпись (approved-инвариант).
|
||||
3. **Транскрипция имён как per-book policy** (Палладий/Поливанов vs фандомные формы) — флаг книги,
|
||||
детерминированно энфорсится; надо ли сейчас или в слой 2 позже?
|
||||
4. **Бюджет пакета §D** (~$8–15 оценочно) — ок в рамках ключей?
|
||||
**Бэкенду (трек A, к сведению — стройка гейтится §D):**
|
||||
5. `Chunk` расширяется аддитивно (BoundaryClass/SceneID/OversizedFlag); контракт
|
||||
Chapter/ChunkIdx/Text не трогается; golden — чанкер-фикстура на legacy-эквивалентность greedy.
|
||||
⚠ Лендинг chunker-конфига в снапшот сам по себе = одноразовый `--resnapshot` (полная переоплата
|
||||
in-flight книги) + сознательный golden re-capture — плановое событие, не сюрприз (§B1.1).
|
||||
6. Кнобы когезии — НОВЫЕ имена `carryover_sentences`/`lookahead_sentences` (не переворачивать
|
||||
единицы мёртвых `stm_depth`(чанки)/`overlap_tokens`(токены); те снести — они dead-but-snapshot-live).
|
||||
7. Дифф-apply машинерия (§C2) — та самая парковка D21.4/D21.10; спека здесь, стройка после Q4b.
|
||||
Плюс carryover-путь требует: новый версионируемый ru-сегментер (НЕ оракульный из coverage.go)
|
||||
+ `carryoverVersion`-фолд + проводка prev-final/next-chunk через translateChunk (§B3).
|
||||
8. **Проверить слаги DeepSeek до 2026-07-24:** официальная дока объявила deprecation legacy-имён
|
||||
`deepseek-chat`/`deepseek-reasoner` 24.07 15:59 UTC (маппинг на v4-flash). Конфиг на
|
||||
`deepseek-v4-flash/pro` — вероятно не задет; eval-скрипты проверить грепом (правило двух направлений).
|
||||
8-бис. **Вендор-чек префикс-кэша ZAI/GLM (до опоры на warm-then-fan/COGS-выводы):** GLM — фактический
|
||||
editor и самая дорогая стадия; его кэш-семантика/скидка НЕ верифицированы (официальная дока
|
||||
z.ai/bigmodel.cn, правило двух направлений). Вся кэш-экономика §B3-бис/Q2c условна на этом чеке.
|
||||
**Оркестратору:**
|
||||
9. §D исполняется полигоном ПОСЛЕ вашей верификации этого отчёта (author≠reviewer соблюдён:
|
||||
я не гоняю платную эмпирику). Приоритет: Q2b — бесплатный и бьёт прямо в центральный конфликт.
|
||||
10. Веб-фактура отчёта: 65-агентный workflow; 52 клейма получили явный вердикт верификатора
|
||||
(36 CONFIRMED / 16 OVERSTATED с коррекциями — коррекции внесены в текст или §B0). Полное
|
||||
приложение (клеймы + URL + вердикты) — `docs/research/19-chunking-cohesion-sources.md`
|
||||
(лендить вместе или отдельно — на ваше усмотрение). Пост-хок само-ревью отчёта: 5-линзовый
|
||||
адверсариальный workflow (репо-грунтовка / верность цитат / методология §D / Go-реализуемость /
|
||||
консистентность) — 8 MAJOR-находок исправлены в тексте до сдачи (общий знаменатель трапов,
|
||||
Q2a-конфаунд, reflow-инвариантный omission, двойной якорь A0, карта независимости сигналов,
|
||||
снапшот-механика carryover, невыровненный билингв-хвост, кэш ZAI не верифицирован).
|
||||
Loading…
Add table
Reference in a new issue