Land an independent critique that calls the main hypothesis open, and take back an inference the review header had listed as proven
This commit is contained in:
parent
75ae6f06ca
commit
c9dfde5ea1
5 changed files with 451 additions and 1 deletions
|
|
@ -15,7 +15,7 @@
|
|||
> **A_law/F3 +2.81** по Холму (§1.2) · нога «канон-фиксер по флагам» **измерена и ПАЛА**, `C2/A_law
|
||||
> −3.75` (§1.3) · `glm-5` РЕДАКТОРОМ неотличим от `deepseek-v4-pro`, ОДНОПРОХОДКОЙ — различимо хуже
|
||||
> (§2.2) · медиана **96%** предложений финала встречается в трейсе размышления дословно (§2.2, самый
|
||||
> сильный внутренний довод за топологию) · экономика **$127 / $20 / $62** и редактор = 90% денег
|
||||
> сильный внутренний довод за топологию) ⚠ **ЭРРАТА 06.09: ЗАМЕР и ВЫВОД из него — разное, и вывод ОСПОРЕН.** Сам замер (96% в трейсе) держится; но вывод «значит внешний дешёвый черновик — тот же черновик, который дорогая модель пишет внутри себя» опровергает независимая критика `research/31` п.5: наличие текста будущего ответа в размышлении СИЛЬНОЙ модели не делает ВНЕШНИЙ дешёвый черновик эквивалентным её собственной работе. Здесь он стоял под «ЧТО ДОКАЗАНО» — это моя ошибка: доказан ЗАМЕР, а не вывод. ⇒ «самый сильный внутренний довод за топологию» снято до разрешения спора. · экономика **$127 / $20 / $62** и редактор = 90% денег
|
||||
> связки (§2.4) · эхо-мина: связка **9 из 10** глав против **10/10** у однопроходки (§2.3) ·
|
||||
> **59 блокирующих претензий на 17 глав = 3.5 на главу** при планке ≤2, уложилась 1 глава из 17, при
|
||||
> этом все 17 вычитчиков независимо сказали «читается как книга» (§3.1) · остаток, недоступный
|
||||
|
|
|
|||
107
docs/research/31-harness-audit/context_probe_test.go.txt
Normal file
107
docs/research/31-harness-audit/context_probe_test.go.txt
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
package pipeline
|
||||
|
||||
import (
|
||||
"context"
|
||||
"crypto/sha256"
|
||||
"encoding/json"
|
||||
"os"
|
||||
"path/filepath"
|
||||
"strings"
|
||||
"testing"
|
||||
|
||||
"textmachine/backend/internal/llm"
|
||||
)
|
||||
|
||||
// This is a request-capture probe, not a model-quality test. It executes the
|
||||
// actual book runner and current production prompt files with an in-memory
|
||||
// provider. Every response is synthetic and no network client is called.
|
||||
type contextAuditClient struct{ requests []llm.LLMRequest }
|
||||
|
||||
func (c *contextAuditClient) Complete(_ context.Context, r llm.LLMRequest) (*llm.LLMResponse, error) {
|
||||
c.requests = append(c.requests, r)
|
||||
body, _ := json.Marshal(r.Messages)
|
||||
output := "Наконец согласился."
|
||||
if strings.Contains(string(body), "女孩") {
|
||||
output = "Девушка одна сидела в комнате и обдумывала просьбу."
|
||||
}
|
||||
if strings.Contains(string(body), "男孩") {
|
||||
output = "Юноша один сидел в комнате и обдумывал просьбу."
|
||||
}
|
||||
return &llm.LLMResponse{Text: output, Model: r.Model, FinishReason: llm.FinishStop,
|
||||
Usage: llm.Usage{PromptTokens: 100, CompletionTokens: 20}}, nil
|
||||
}
|
||||
|
||||
func TestAuditContextAcrossEditUnits(t *testing.T) {
|
||||
current := "终于答应了。"
|
||||
prefixes := []string{"女孩独自坐在房里，反复考虑那个请求。", "男孩独自坐在房里，反复考虑那个请求。"}
|
||||
var captures [2][]llm.LLMRequest
|
||||
for variant, prefix := range prefixes {
|
||||
bookPath := setupProjectOpts(t, "http://127.0.0.1:1", projectOpts{
|
||||
source: prefix + "\f" + current, banknote: true, waveWorkers: 1})
|
||||
projectDir := filepath.Dir(bookPath)
|
||||
bookBytes, err := os.ReadFile(bookPath)
|
||||
if err != nil {
|
||||
t.Fatal(err)
|
||||
}
|
||||
writeFile(t, bookPath, strings.Replace(string(bookBytes), "source_lang: ja", "source_lang: zh", 1))
|
||||
for _, pair := range [][2]string{{"translator-banknote.md", "translator.md"}, {"editor.md", "editor.md"}} {
|
||||
data, err := os.ReadFile(filepath.Join("..", "..", "prompts", "zh-ru", pair[0]))
|
||||
if err != nil {
|
||||
t.Fatal(err)
|
||||
}
|
||||
writeFile(t, filepath.Join(projectDir, "prompts", pair[1]), string(data))
|
||||
}
|
||||
r := newRunner(t, bookPath)
|
||||
chunks, err := r.bookChunks()
|
||||
if err != nil {
|
||||
r.Close()
|
||||
t.Fatal(err)
|
||||
}
|
||||
units := buildEditUnits(chunks)
|
||||
if len(units) != 2 || len(units[0].Members) != 1 || len(units[1].Members) != 1 ||
|
||||
units[0].Chapter == units[1].Chapter || units[1].sourceText() != current {
|
||||
r.Close()
|
||||
t.Fatalf("fixture did not cross an edit-unit boundary: chunks=%+v units=%+v", chunks, units)
|
||||
}
|
||||
fake := &contextAuditClient{}
|
||||
r.clients["fake-model"] = fake
|
||||
result, err := r.TranslateBook(context.Background())
|
||||
r.Close()
|
||||
if err != nil {
|
||||
t.Fatal(err)
|
||||
}
|
||||
if len(fake.requests) != 4 || result.Flagged != 0 {
|
||||
t.Fatalf("want 2 draft+2 edit calls, clean result; calls=%d result=%+v", len(fake.requests), result)
|
||||
}
|
||||
captures[variant] = fake.requests
|
||||
t.Logf("variant=%d: 2 chapters / 2 draft chunks / 2 edit units / %d in-memory provider calls; previous=%s", variant, len(fake.requests), prefix)
|
||||
}
|
||||
var currentByVariant [2][]llm.LLMRequest
|
||||
var priorByVariant [2][]llm.LLMRequest
|
||||
for variant, reqs := range captures {
|
||||
for _, req := range reqs {
|
||||
b, _ := json.Marshal(req.Messages)
|
||||
if strings.Contains(string(b), current) {
|
||||
currentByVariant[variant] = append(currentByVariant[variant], req)
|
||||
} else {
|
||||
priorByVariant[variant] = append(priorByVariant[variant], req)
|
||||
}
|
||||
}
|
||||
if len(currentByVariant[variant]) != 2 || len(priorByVariant[variant]) != 2 {
|
||||
t.Fatal("missing draft/editor captures")
|
||||
}
|
||||
}
|
||||
for i, role := range []string{"draft", "editor"} {
|
||||
a, _ := json.Marshal(currentByVariant[0][i])
|
||||
b, _ := json.Marshal(currentByVariant[1][i])
|
||||
if string(a) != string(b) {
|
||||
t.Fatalf("current %s request DID change with preceding context: A=%s B=%s", role, a, b)
|
||||
}
|
||||
pa, _ := json.Marshal(priorByVariant[0][i])
|
||||
pb, _ := json.Marshal(priorByVariant[1][i])
|
||||
if string(pa) == string(pb) {
|
||||
t.Fatalf("prior %s requests should differ", role)
|
||||
}
|
||||
t.Logf("current %s request is byte-identical: bytes=%d sha256=%x; prior request differs", role, len(a), sha256.Sum256(a))
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
package membank
|
||||
|
||||
import (
|
||||
"strings"
|
||||
"testing"
|
||||
|
||||
"textmachine/backend/internal/lang"
|
||||
"textmachine/backend/internal/store"
|
||||
)
|
||||
|
||||
// This probe executes the current loader, matcher and renderer. It does not
|
||||
// claim that the rejected rows can reach the production render path.
|
||||
func TestAuditPolysemyLoaderVersusRenderer(t *testing.T) {
|
||||
const surname = " - src: 青山\n sense: surname\n dst: Циншань\n status: approved\n"
|
||||
const landscape = " - src: 青山\n sense: direction\n dst: зелёная гора\n status: approved\n"
|
||||
const source = "青山在等。青山在远方。"
|
||||
|
||||
// Both individual records are valid; refusal is specifically about their
|
||||
// coexistence, not malformed YAML or an unsupported field.
|
||||
var rows []store.GlossaryEntry
|
||||
for _, raw := range []string{surname, landscape} {
|
||||
one, err := ParseBankSeed("one-record.yaml", []byte("terms:\n"+raw))
|
||||
if err != nil || len(one.Terms) != 1 {
|
||||
t.Fatalf("a single record must load: rows=%d err=%v", len(one.Terms), err)
|
||||
}
|
||||
rows = append(rows, one.Terms...)
|
||||
}
|
||||
_, err := ParseBankSeed("both-approved.yaml", []byte("terms:\n"+surname+landscape))
|
||||
if err == nil || !strings.Contains(err.Error(), "OVERLAPPING") {
|
||||
t.Fatalf("expected specific overlapping-senses refusal, got %v", err)
|
||||
}
|
||||
t.Logf("same seed, two approved senses: REFUSED: %v", err)
|
||||
|
||||
// Putting the individually valid records in different input files cannot
|
||||
// make a real run accept them: the production gather checks the joined rows.
|
||||
cols := ApprovedSharedKeyCollisions(rows)
|
||||
if len(cols) != 1 {
|
||||
t.Fatalf("joined-input collision guard must refuse exactly one pair: %v", cols)
|
||||
}
|
||||
t.Logf("two individually valid files, joined rows: REFUSED: %s", cols[0])
|
||||
|
||||
// Deliberately enter BELOW the loader, as the existing render test does.
|
||||
// The real matcher and renderer preserve both signed meanings here.
|
||||
bank := Materialize(rows, false)
|
||||
sel := bank.Select(source, 1, nil, 800)
|
||||
if len(sel.Injected) != 2 {
|
||||
t.Fatalf("expected both entries to match below loader, got %d", len(sel.Injected))
|
||||
}
|
||||
block := RenderEditorConstraintBlock(sel.Injected, lang.InjectionTextsFor("ru"))
|
||||
for _, want := range []string{"青山 → «Циншань»", "青山 → «зелёная гора»"} {
|
||||
if !strings.Contains(block, want) {
|
||||
t.Fatalf("renderer dropped signed sense %q: %s", want, block)
|
||||
}
|
||||
}
|
||||
t.Logf("below loader, actual matcher+renderer: BOTH signed senses retained:\n%s", block)
|
||||
|
||||
// Control: disjoint chapter windows really are supported, and never place
|
||||
// both signed meanings in the same injection.
|
||||
disjoint := "terms:\n" + surname + " until_ch: 1\n" + landscape + " since_ch: 2\n"
|
||||
bs, err := ParseBankSeed("disjoint-windows.yaml", []byte(disjoint))
|
||||
if err != nil {
|
||||
t.Fatalf("non-overlapping windows must load: %v", err)
|
||||
}
|
||||
bank = Materialize(bs.Terms, false)
|
||||
for _, ch := range []int{1, 2} {
|
||||
if n := len(bank.Select(source, ch, nil, 800).Injected); n != 1 {
|
||||
t.Fatalf("disjoint chapter %d must select one meaning, got %d", ch, n)
|
||||
}
|
||||
}
|
||||
t.Log("non-overlapping windows: ACCEPTED; one selected meaning in each chapter")
|
||||
|
||||
// The current diagnostic suggests status:auto; with the same nonempty dst
|
||||
// this does not bypass the same-file guard (it never checks status).
|
||||
auto := strings.Replace(landscape, "status: approved", "status: auto", 1)
|
||||
_, err = ParseBankSeed("one-auto.yaml", []byte("terms:\n"+surname+auto))
|
||||
if err == nil || !strings.Contains(err.Error(), "OVERLAPPING") {
|
||||
t.Fatalf("auto with nonempty dst must still hit current same-file guard: %v", err)
|
||||
}
|
||||
t.Log("status:auto with nonempty dst in the same seed: still REFUSED")
|
||||
}
|
||||
114
docs/research/31-harness-independent-critique.md
Normal file
114
docs/research/31-harness-independent-critique.md
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
**Независимая критика подхода TextMachine — 06.09.2026**
|
||||
|
||||
> **⟶ СТАТУС (проставлен оркестратором 06.09): ФАКТУРА, НЕ РАТИФИЦИРОВАНА.** Отчёт заказан владельцем
|
||||
> у независимой сессии Codex и заландён оркестратором как есть — правок в тело не вносилось.
|
||||
> ⛔ **Полная ревью-шапка «что доказано / что СНЯТО / что не проверено» ещё НЕ написана — долг
|
||||
> оркестратора.** До неё ни одно утверждение отсюда не цитируется как ратифицированное.
|
||||
>
|
||||
> ⚠ **ЧЕМ ЭТОТ ОТЧЁТ ОТЛИЧАЕТСЯ ОТ `research/29`/`30` и почему его нельзя читать как их продолжение:**
|
||||
> те мерили ВНЕШНИЙ мир и сверяли его с нами; этот судит НАШ СОБСТВЕННЫЙ выбор архитектуры и прямо
|
||||
> называет кандидатов на пересмотр. Его вердикт — «главная гипотеза остаётся ОТКРЫТОЙ» — противоречит
|
||||
> тону, в котором смена 05–06.09 принимала паки, и это противоречие разрешает ВЛАДЕЛЕЦ, а не я.
|
||||
>
|
||||
> ⚠ **Одно его утверждение задевает уже проставленную ревью-шапку `research/30` — эррата внесена
|
||||
> 06.09 в неё саму** (о трейсе размышления, п.5 этого отчёта).
|
||||
|
||||
Автор: Codex. Заказ: оценить способ достижения издательского качества, верхнеуровневую архитектуру и направление развития. Статус: исследовательское мнение для оркестратора; не ратификация и не задание менять код.
|
||||
|
||||
**Пересмотр после замечания владельца, 06.09:** прежняя рекомендация безусловно сохранить две волны была сверхвыводом. Локальные гарантии исполнения не доказывают правильность переводческой топологии. Формулировки ниже сужены; конкретные альтернативы и проверка их предшественников — в [продолжении](32-harness-architecture-alternatives.md).
|
||||
|
||||
Основа проверки: рабочее дерево при HEAD `6ace7e1be67ca20525736e8e64c35c525a8f01b4`, включая незакоммиченную работу над структурой глав. Код и оплаченные прогоны не изменялись. Числа старых экспериментов ниже — из их отчётов, не новый замер автора. Внешние первоисточники проверены 06.09.2026.
|
||||
|
||||
**Вердикт.** Движок содержит полезные механизмы контролируемого исполнения, но это не основание считать выбранную архитектуру перевода сильной целиком. Главная гипотеза — «этот харнесс устойчиво даёт лучший литературный перевод книги за приемлемую полную цену» — остаётся открытой. Опасный сдвиг курса: считать соблюдение канона и отсутствие механически видимого брака достаточной заменой сохранению смысла, голоса и авторских решений. Глобальный барьер волн и ранняя фиксация канона — кандидаты на пересмотр.
|
||||
|
||||
**Что следует сохранить как требования к любой архитектуре.** Ограничение повторов, воспроизводимое происхождение запросов, сохранение оплаченного ответа вместе с учётом расхода, явное владение состоянием. Конкретные волны, банк и границы snapshot этими требованиями не предопределены. Подпись термина уже допускает бесплатное переиспользование незатронутых фрагментов — утверждение «любая правка банка перепокупает всю книгу» неверно (`backend/internal/pipeline/stagerun.go:91`, `backend/internal/store/ledger.go:178`).
|
||||
|
||||
Рабочая схема — C1, черновик → редактор, с банковым контуром и детерминированными проверками. Судья-селектор в рабочем пути отсутствует: `CheckRunnable` запрещает `role=judge` и fanout > 1 (`backend/internal/config/pipeline.go:492`). Это допустимое упрощение; оно означает, что обещания смыслового контроля нельзя обосновывать нарисованной ролью судьи.
|
||||
|
||||
**1. Самая срочная поправка — измерять верность оригиналу, а не верность черновику.**
|
||||
|
||||
В свежем протоколе первичный показатель точности задан относительно черновика. Судья получает черновик и два редакторских результата; китайский оригинал ему не предъявлен (`eval/dovodka/blind-read/PREREG-2-BLIND-READ.md:62`; `PREREG-BLIND-READ.md:27`, `:77`). Ограничение честно записано, но такая проверка не может разрешать вопрос о смысловой безопасности редактора.
|
||||
|
||||
Пример: переводчик перепутал действующего персонажа. Редактор A сохранил ошибку, B исправил по оригиналу. Проверка на верность черновику способна наградить A и наказать B. Это неверно выбранная опора, которую не исправит увеличение числа судей.
|
||||
|
||||
Есть и второе смешение. D39.198 связывает консистентность с банком, выдумки с редактором (`docs/architecture/05-decisions-log.md:2231`). Это разумные места начала диагностики, но не установленные причины: ошибочный факт может прийти из черновика, банка или редакторского прохода.
|
||||
|
||||
**Коррекция:** сохранить раздельные приоритеты владельца, но оценивать конечный перевод по оригиналу; происхождение дефекта устанавливать сравнением `source → draft → final` с фактически поданным банком. Неизвестное происхождение так и обозначать. Русскую читаемость оценивать отдельно. В существующую карточку дефекта достаточно добавить источник ошибки и ссылки на соответствующие фрагменты — новая роль движка для этого не нужна.
|
||||
|
||||
**2. Борьба с ложными доказательствами сама породила ложное опровержение.**
|
||||
|
||||
В `RESULT-2-BLIND-READ.md:9–20` два случайных перевода одного режима объявлены обязанными получить ничью; выбор победителя в 29/30 оценок трактуется как неисправность прибора. Вывод неверен: два разных результата одного режима могут действительно иметь разное качество. Нулевая гипотеза касается среднего преимущества режима, а не обязательной ничьей каждой пары. В `:65–67` сам отчёт признаёт различие конкретных реализаций.
|
||||
|
||||
Это не доказывает исправность судьи. Это снимает именно предъявленное основание его дисквалификации. По нему уже предложено не покупать судейские панели (`docs/research/30-arhitektura-otvet.md:345`). Также правило `PREREG-2-BLIND-READ.md:89` разрешает вывод «не хуже», если значимый вред не найден; результат в `RESULT-2-BLIND-READ.md:87` уже правильно запрещает такое заключение.
|
||||
|
||||
**Коррекция:** разнести три проверки: одинаковые тексты и перестановки позиций проверяют оценщик; повторные генерации измеряют разброс генератора; заведомо испорченные и проверенные хорошие переводы проверяют чувствительность к качеству. Неухудшение требует заранее выбранной допустимой потери и доверительного интервала. Сохранить честный итог текущего замера: превосходство не показано; равенство также не установлено. Не выводить из этого отказ от сравнительной оценки вообще.
|
||||
|
||||
**3. Банк обеспечивает единообразие решения, но может размножать единообразную ошибку.**
|
||||
|
||||
Банковская строка, отобранная для инъекции и содержащая перевод, подаётся обязательным правилом независимо от подписи (`backend/internal/membank/memory.go:826`). Это осознанная политика против расхождения параллельных фрагментов. Но `mempostcheck.go:11–16` обещает ловить даже подчинение неверному банковскому переводу, тогда как реализация проверяет присутствие этого самого перевода и при наличии принимает его (`:116–125`). Данным алгоритмом такое обещание невыполнимо.
|
||||
|
||||
Это уже не только теоретический риск: в небольшой прежней пробе ошибочная строка была принята в 6/6 окон и вытеснила правильную в 5/6 (`docs/research/24-bank-arbitration.md:253–269`). Это результат конкретной модели и материала; процент нельзя переносить на нынешний полный движок. Он достаточен, чтобы перестать считать послушание проверкой правильности.
|
||||
|
||||
**Коррекция:** единый канон сохранить; различать соблюдение формы, правильность выбранного значения и правильность привязки к персонажу/контексту. Сравнить автоматический банк, независимо проверенный банк и отсутствие банка; добавить несколько правдоподобно ошибочных записей. Считать ущерб по последующим употреблениям сущности, а не только по числу строк. Если вред подтверждается, исправлять допуск и пересмотр банковского решения. Возвращение маркера «проверь» само по себе уже не имеет убедительной поддержки этой пробы.
|
||||
|
||||
На длинной книге есть второй вопрос: сохраняется ли полезный банк при порционном переводе. Лимит майнера применяется до части фильтров, авто-банк пересобирается, банковые батчи при новых свидетельствах могут менять запрос и покупаться повторно (`backend/internal/miner/miner_emit.go:119`; `backend/internal/pipeline/mining.go:697`; `backend/internal/pipeline/terminologist.go:775`, `:849`). Проверка роста 10 → 50 → 200 глав против обработки того же текста сразу должна считать удержанные решения, новые ошибки и общую цену. Расширять майнер до такого сравнения необязательно.
|
||||
|
||||
**4. Словарь книги пока не заменяет понимание её повествования.**
|
||||
|
||||
Редактор получает исходник и черновик собственной единицы. Подбор банка у редактора идёт без предыдущего sticky-контекста (`backend/internal/pipeline/waverun.go:689–706`); вход рендера не несёт соседнего повествования (`render.go:178–210`). Профили голосов заведены, но их инъекция намеренно не включена (`bankmaterialize.go:290–307`). Следовательно, наличие банка и таблиц голосов ещё не означает передачу межглавных связей и индивидуальной речи модели.
|
||||
|
||||
Контрпример проверен исполнением: две книги различаются персонажем в предыдущей главе; следующая начинается одинаковым «终于答应了» — «наконец согласился/согласилась». Реальный `TranslateBook` с текущими zh→ru промптами и подставным провайдером дал разные запросы предыдущих единиц и побайтно одинаковые запросы текущих переводчика и редактора. Условия: пустой одинаковый банк, майнинг выключен, банкнота включена; две главы и две редакторские единицы на вариант. Это проверка доступности информации; частоту неправильных переводов живой модели она не устанавливает. Артефакт и воспроизведение — в конце документа.
|
||||
|
||||
Отрицательные результаты carryover не закрывают весь класс: в exp15 широкое чтение, lookahead и состояние сцены остались неисполненными (`docs/experiments/15-segmentation-empirics.md:489`). Сам target-architecture ограничивает перенос результатов классом исследованных книг (`docs/architecture/09-target-architecture.md:134`). Работа над структурой глав полезна, но она отвечает на другой вопрос.
|
||||
|
||||
**Коррекция:** проверить зависимости через границы редакторских единиц: субъект, адресат, намеренная неоднозначность, смена регистра, позднее раскрытие смысла термина. Сначала сравнить текущий вход с минимальным необходимым исходным контекстом; затем выбирать окно, поиск исходных фрагментов или состояние сцены. Не начинать со строительства универсальных summaries/графа. В строке 80 бэклога (`docs/PROGRESS.md:153`) уточнить: ссылка на исходник проверяется детерминированно, её семантическое толкование — нет. Требование безошибочного детерминированного толкования заранее заблокирует исследование этой задачи.
|
||||
|
||||
**5. Черновик → редактор — рабочая гипотеза, которую нельзя превращать в неприкосновенную основу.**
|
||||
|
||||
Польза редактора поверх слабого черновика измерена; утверждение «всё построено без экспериментов» неверно. Но это другой вопрос, чем выигрыш у сильной модели, переводящей непосредственно с оригинала при сопоставимом контексте и цене. Сравнения уже были, однако их ограничения и поздние отзывы не позволяют объявлять вопрос закрытым (`docs/experiments/21-role-topology.md:958`; `23-editor-tier.md:7322–7385`).
|
||||
|
||||
Два аргумента в `docs/research/30-arhitektura-otvet.md:136–142` не следуют из данных. Наличие текста будущего ответа в reasoning сильной модели не делает внешний дешёвый черновик эквивалентным её собственной работе. И зависимость нынешнего терминолога от черновика не доказывает невозможность добывать банк из оригинала. Это свойство реализации, не необходимость предметной области.
|
||||
|
||||
**Коррекция:** держать прямой сильный перевод обязательным соперником. Одинаковый готовый банк уравнивает банковые условия; для выделения эффекта черновика также уравнять финальную модель, усилие, содержательное задание и исходный контекст. Даже такое сравнение НЕ доказывает, что можно бесплатно убрать производство черновика из банкового контура. Отдельно сравнить полные конфигурации, включая вариант с извлечением банка из оригинала и всю его цену. Если проще получается не хуже в заранее заданных пределах и дешевле по полной стоимости, сокращать стадии. Если связка выигрывает — сохранять по этому результату.
|
||||
|
||||
Сюда же относится задача борьбы с translationese: «живой литературный русский» и обязательная гипотактическая перевёрстка (`backend/prompts/zh-ru/editor.md:15–19`) могут помогать плоскому построчному тексту, но не являются универсальным стилем всех авторов. Повторы уже частично защищены промптом. Остальную авторскую намеренность следует проверять на контрастных книгах, а не максимизировать гладкость, разнообразие или длину абзаца.
|
||||
|
||||
**6. Следующий полезный инфраструктурный шаг — удешевить изменение решения о качестве.**
|
||||
|
||||
Snapshot волны входит в адрес оплаченного ответа; бесплатный перенос через изменение snapshot сейчас разрешён для банкового изменения, но не для изменения гейта (`backend/internal/pipeline/render.go:369`; `repin.go:44–48`). Изменение проверки, включённой в snapshot, поэтому способно потребовать повторных запросов при прежних входных сообщениях. Это не относится к каждой наблюдательной ручке: например, включение `regression_guard` не двигает snapshot. Такая связь оплаты с вердиктом удорожает обучение проекта на уже оплаченных книгах.
|
||||
|
||||
Направление D15.2 — отделить идентичность запроса/ответа от версии вердикта — правильное и уже запланировано. Его стоит поднять относительно новых проверяющих ролей. Старую спеку нельзя исполнять буквально: она предшествует нынешним волнам и предусматривает миграционную перепокупку (`backend/docs/D15.2-content-addressed-resume-spec.md:3`, `:479`). Критерий нового дизайна: изменение только проверки переоценивает сохранённые ответы без LLM-вызовов. Сохранение черновика при смене только редактора уже обеспечено раздельными снапшотами волн (`backend/internal/pipeline/snapshot.go:224`) — эту гарантию сохранить. Совместимость со старыми оплаченными артефактами — часть задачи.
|
||||
|
||||
**Положение относительно конкурентов.**
|
||||
|
||||
Это сравнение публично подтверждённых возможностей, не испытание чужого качества. Закрытые реализации не проверены; маркетинговые проценты точности не приняты за результаты.
|
||||
|
||||
| Система и первоисточник | Что уже существует публично | Следствие для TextMachine |
|
||||
|---|---|---|
|
||||
| [Translate a Book](https://translateabook.com/) | Анализ книги, редактируемый справочник персонажей/терминов/стиля, референсный перевод, саморедактура и карточки проверки; русский заявлен | «Глоссарий + редактор + референсы» уже не уникальное предложение |
|
||||
| [EditBook.ai](https://editbook.ai/auth/examples/translation) | План по всей рукописи, перевод глав, редактура, межглавная проверка терминов, сопоставление с оригиналом и ручные правки | Литературный IDE и многоэтапность также заняты; качество и поддержка нашей пары требуют отдельной проверки |
|
||||
| [LinguaGacha](https://github.com/neavo/LinguaGacha/blob/main/README_EN.md) | Открытый переводческий инструмент с глоссарием и рабочим местом проверки, в том числе для книг | Соперники включают готовые специализированные инструменты, а не только голые API |
|
||||
| [DelTA](https://arxiv.org/abs/2410.08143) | Документный перевод с памятью собственных имён, двуязычными резюме и предыдущими переводами | Работа с контекстом шире глоссария уже исследуется; это ещё не доказательство необходимости именно такого решения у нас |
|
||||
| [LAIT, §2.1 и §3](https://arxiv.org/html/2606.26040v1) | Сильный агентный конвейер с локальными и общими проверками; отдельная читательская оценка | Авторы не считают выбор сложной схемы доказательством её решающего превосходства; качество требует проверки людьми, а число проходов его не устанавливает |
|
||||
|
||||
TextMachine содержит проверяемые механизмы исполнения; сравнения надёжности архитектур на одинаковой нагрузке здесь не было. По доказанному качеству длинной книги лидерство не установлено. По части доступных пользовательских возможностей конкуренты уже предъявляют то, что у нас остаётся планом. И заявления «впереди всех», и заявления «конкуренты переводят лучше» сейчас выходят за имеющиеся данные. Перечни функций в research/02 и 22 нельзя использовать как рейтинг качества или себестоимости.
|
||||
|
||||
**Ближайший цикл решения, который я рекомендую оркестратору.**
|
||||
|
||||
1. Исправить смысл трёх существующих утверждений: опора оценки — оригинал; случайные реализации не обязаны получать ничью; postcheck проверяет соблюдение банковской формы. Это работа с текущими протоколами и описаниями, без нового конвейера.
|
||||
2. После уже идущих блокирующих работ провести ограниченное сравнение текущего полного движка и сильного прямого перевода на нескольких свежих книгах. Нужны связные отрывки с переходами между главами и поздними появлениями сущностей; ещё одна языковая пара проверяет переносимость отдельно от zh→ru. Не подменять такую проверку одними синтетическими сценами или известной модели вебновеллой.
|
||||
3. Раздельно получить: ошибки смысла по оригиналу; сохранение авторского/персонажного голоса; соблюдение и правильность канона; время человеческой доводки; полную цену вместе с банком, повторными вызовами и исправлениями. Не сводить это в один произвольный балл. Часть оценки должен сделать независимый двуязычный читатель; согласие нескольких LLM не заменяет его.
|
||||
4. Заранее определить допустимое ухудшение и правило выбора. Группировать результаты по книгам и исходным единицам: дополнительные голоса судей не увеличивают число независимых текстов. На части материала повторить генерацию обеих схем для оценки разброса внутри конфигурации. При неопределённом результате решение остаётся управленческим, с явной ценой неопределённости. Малый тест выявляет крупный провал и направляет следующий шаг; он не доказывает отсутствие редких ошибок на тысячах глав.
|
||||
5. Новую память, критика или ремонтный проход строить под обнаруженный класс остаточных ошибок и проверять сравнением с вариантом без него. Для банка дополнительно измерить внесённый вред; для контекста — доступность нужного факта; для редактора — пользу и новые ошибки одновременно.
|
||||
|
||||
**Сигнал менять направление:** простой соперник выигрывает при той же планке готовности; автоматический банк увеличивает смысловые ошибки; выигрыш остаётся только в знакомой книге/разметке; новые проходы уменьшают флаги, но увеличивают ручную доводку. При этих исходах надо упрощать или менять соответствующий механизм. Архитектурные ограничения представления можно устанавливать кодом ещё до такого замера; конкретные альтернативы разобраны в продолжении. Сохранять полезные гарантии исполнения не означает заранее сохранять топологию.
|
||||
|
||||
**Границы этой проверки.** Прочитаны стартовый бриф, промпт оркестратора, основные архитектурные документы и актуальные планы; исследовательский корпус о переводе, памяти, нарезке, голосах, топологиях и конкурентах; отчёты экспериментов и свежая доводка. Журнал решений читался через индекс и конкретные ноты. Длинные технические хроники backend/docs и контрактное research/28 разобраны по решениям, итогам и остаткам, не построчно целиком. Код проверялся по существенным маршрутам; полного код-аудита и повторения оплаченных экспериментов не было. Независимые параллельные чтения помогли найти противоречия, но не считаются независимостью обучающих корпусов моделей. Архивная критика не принималась за факт текущего дерева; активные правки структуры глав и уже построенная проводка цены учтены.
|
||||
|
||||
**Воспроизводимый артефакт к пункту 4.** [Исходник пробы](31-harness-audit/context_probe_test.go.txt) сохранён отдельно от тестов продукта. В отдельной копии `backend` без ключей поместить его в `internal/pipeline/engine_logic_audit_test.go` и выполнить из корня этой копии:
|
||||
|
||||
```sh
|
||||
go test ./internal/pipeline -run '^TestAuditContextAcrossEditUnits$' -count=1 -v
|
||||
```
|
||||
|
||||
Исполнено в `/tmp/textmachine-engine-logic-audit-09z7llyi`: PASS, восемь вызовов подставного клиента, без сетевых/платных LLM-вызовов. Тест проверяет границы настоящего манифеста и сравнивает все поля `LLMRequest`. Совпавшие запросы: переводчик — 3910 байт, SHA256 `f852ea316880644b60124500cbcc9b2ba10b9c0bb2d791e4a7ba543b62e1ea1f`; редактор — 7008 байт, SHA256 `e733dbca09e807d29bc4b3b36bb780be03afd00e71356a01c1169281b6e72c80`. Это снимок указанных промптов и фикстуры, не обещание неизменных хешей после их правки. Конфигурация использует инфраструктуру тестов движка; это не полный боевой C1-прогон и не оценка качества синтетических ответов.
|
||||
149
docs/research/32-harness-architecture-alternatives.md
Normal file
149
docs/research/32-harness-architecture-alternatives.md
Normal file
|
|
@ -0,0 +1,149 @@
|
|||
**Пересмотр архитектурного вывода и конкретные альтернативы — 06.09.2026**
|
||||
|
||||
> **⟶ СТАТУС (проставлен оркестратором 06.09): ФАКТУРА, НЕ РАТИФИЦИРОВАНА.** Отчёт заказан владельцем
|
||||
> у независимой сессии Codex и заландён оркестратором как есть — правок в тело не вносилось.
|
||||
> ⛔ **Полная ревью-шапка «что доказано / что СНЯТО / что не проверено» ещё НЕ написана — долг
|
||||
> оркестратора.** До неё ни одно утверждение отсюда не цитируется как ратифицированное.
|
||||
>
|
||||
> ⚠ **ЧЕМ ЭТОТ ОТЧЁТ ОТЛИЧАЕТСЯ ОТ `research/29`/`30` и почему его нельзя читать как их продолжение:**
|
||||
> те мерили ВНЕШНИЙ мир и сверяли его с нами; этот судит НАШ СОБСТВЕННЫЙ выбор архитектуры и прямо
|
||||
> называет кандидатов на пересмотр. Его вердикт — «главная гипотеза остаётся ОТКРЫТОЙ» — противоречит
|
||||
> тону, в котором смена 05–06.09 принимала паки, и это противоречие разрешает ВЛАДЕЛЕЦ, а не я.
|
||||
>
|
||||
> ⚠ **Одно его утверждение задевает уже проставленную ревью-шапку `research/30` — эррата внесена
|
||||
> 06.09 в неё саму** (о трейсе размышления, п.5 этого отчёта).
|
||||
|
||||
Автор: Codex. Продолжение [первого отчёта](31-harness-independent-critique.md) по замечанию владельца: нужны решения основной задачи, а не только критика измерений; нельзя заново предлагать уже пройденные идеи. Статус: предложения, не ратификация и не заказ менять движок. Сверено с рабочим деревом при HEAD `6ace7e1be67ca20525736e8e64c35c525a8f01b4`; активные изменения структуры глав учтены. Платные эксперименты не запускались.
|
||||
|
||||
**Мой прежний вывод «ядро сильное, две волны сохранить» был недостаточно обоснован.**
|
||||
|
||||
Я поставил рядом полезные гарантии исполнения и спорную организацию перевода. Атомарное сохранение ответа с оплатой обосновано конкретным отказом между двумя записями. Из этого не следует, что правильно сначала перевести всю разрешённую порцию дешёвой моделью, затем выбрать общий канон, затем отдать текст редактору. Терминолог уже получает контексты оригинала и сам принимает решения — представлять банк простым копированием первого черновика тоже было бы ошибкой. Вопрос в порядке и пересматриваемости решений, а не в полном отсутствии проверки источника.
|
||||
|
||||
Сохранять следует **свойства**: учёт расхода до и после запроса, сохранение оплаченного ответа, известное происхождение входов, ограничение повторов и явное владение состоянием. Я больше не объявляю неприкосновенными текущую схему банка, глобальный барьер волн, идентичность единицы перевода и правила принятия результата. Хорошо работающая реализация неверного представления задачи остаётся неверным представлением.
|
||||
|
||||
Сам проект содержит контрсвидетельство моей прежней уверенности: `research/19-chunking-cohesion.md:556–561` назвал глобальную консолидацию качественно лучшей по аналогии с резюме, но `research/20-bank-mining.md:250–259` уже ограничил перенос: именно превосходство глобальной реконсиляции банка не было установлено. Положительные результаты отдельных редакторских проходов не проверяют этот барьер отдельно.
|
||||
|
||||
**Где архитектура подменяет предметную задачу.**
|
||||
|
||||
| Нынешний контракт — проверено кодом | Что он реально обеспечивает | Чего из этого не следует |
|
||||
|---|---|---|
|
||||
| Совпала исходная строка → подать банковый перевод законом. `backend/internal/membank/memory.go:585–612`, `:925–936` | Выбрать набор словарных указаний для фрагмента | Что найдено именно нужное значение/лицо и что каждое употребление переведено правильно |
|
||||
| Две matchable записи одного `src` с разными `sense/dst` в пересекающихся окнах запрещены. `membank/memseed.go:201–228` | Не допустить противоречивых инструкций нынешнему сопоставителю | Что полисемия внутри главы исчезла из предметной области. Представление не умеет выразить часть легитимных случаев |
|
||||
| Банк определяется до редакторской волны; банкноты извлекает переводческая роль. `pipeline/waverun.go:173`, `:536–550` | Один набор общих решений для параллельной редактуры | Что наиболее содержательное редакторское чтение может исправить общее решение: автоматического обратного пути здесь нет |
|
||||
| Резервируется очередной вызов; весь допущенный draft идёт до edit. `store/ledger.go:44–80`, `pipeline/waverun.go:139–181` | Соблюдать текущий денежный потолок на допуске | Что бюджет будет вложен в законченные главы: остановка внутри draft не переходит к редактору |
|
||||
| Последняя запись `chunk_status` заменяет прежние `FinalHash/Disposition`; export читает текущую финальную стадию. `store/chunkstatus.go:64–88`, `pipeline/export.go:278–299` | Отдать текущее вычисленное состояние | Что это последняя принятая редакция книги и что неудачная повторная редактура не ухудшила доступный результат |
|
||||
|
||||
**Главная проблема логики:** фиксируется не только перевод, но и способ истолковать книгу — часто до того чтения, которое могло бы это истолкование опровергнуть. Затем проверки лучше видят подчинение принятому решению, чем ошибку самого решения. Увеличение числа гейтов такой контур не исправляет.
|
||||
|
||||
**Проверенные исторические развилки: где мог закрепиться неверный поворот.**
|
||||
|
||||
Историю нельзя свести к «раньше ошиблись, теперь надо наоборот». Ниже различены слабое основание решения, чрезмерное обобщение и неполностью проведённый пересмотр.
|
||||
|
||||
| Цепочка | Что именно не выдерживает проверки | Что пересмотреть |
|
||||
|---|---|---|
|
||||
| Глобальная консолидация: заказ владельца на параллельные волны (research/19:534–540) → дополнительное качественное обоснование research/19:556–561 → оговорка research/20:250–259 → D39.12/17 → нынешний `waverun.go` | Это не история «ложные данные заставили построить волны»: выбор отвечал заказу скорости и организации работы. Ошибка — придать ему дополнительный статус качественного превосходства по исследованию резюме. Оговорка о непроверенности переноса была известна; я сам потерял её в отчёте 31 | Сохранить глобальные волны как действующий вариант, но снять их привилегию при сравнении с другим расписанием. Их качество не доказано отдельно от редактора/банка |
|
||||
| Контекст: исправленный exp15 → D39.7/8 от 18.07 → отказ строить carryover → отсутствие его канала в нынешнем входе | Начальный брак рига был исправлен ДО ратификации — обвинять решение в использовании тех старых чисел неверно. Но читательское «подтверждение null» объявлено при нарушенной слепоте и разных объёмах, которые сам отчёт признаёт (`experiments/15-segmentation-empirics.md:538–544`). Проба прямо не устанавливает бесполезность carryover как механизма | Разрешать повторное исследование при новом классе реально потерянной зависимости. Не возвращать удалённые мёртвые ручки автоматически. «Тогда не строить» допустимо; «любому тексту контекст не нужен» из этого не следует |
|
||||
| Полисемия: D16.1 → запрет совпадающего `src` с разными смыслами → D39.193 п.3 от 04.09 признаёт два подписанных канона законными → рендер изменён, входные ограничения остались | Пересмотр уже СОСТОЯЛСЯ в решении, но не проведён через весь путь. Рендер-тест вручную создаёт две записи `青山` (`membank/render_test.go:178–188`), а штатный seed/свод/дверь запрещают соответствующую коллизию (`memseed.go:201–228`; `pipeline/bankmaterialize.go:142`; `membank/decisions.go:914`). Поле `sense` и зелёный тест рендера создают впечатление возможности, которой нет у обычного входа | Согласовать предметный контракт и поддерживаемый путь целиком. Просто удалить запрет опасно: matcher всё ещё не разрешает употребления, а postcheck проверяет наличие формы где-нибудь в единице |
|
||||
| Q4a: сравнение flash/pro на смысловых ловушках → D39.9 → обоснование размещения структуры у редактора в `architecture/10-prompt-architecture.md:13` | На свежем flash не было провалов для расчёта доли исправлений (`experiments/15-segmentation-empirics.md:644–655`). Отказ платить дороже без наблюдаемого выигрыша разумен. Но этот опыт не измерял, какой роли поручить структуру: `09-target-architecture.md:111–114` сам называет такой контракт неизмеренным | Снять с Q4a функцию доказательства распределения структурных задач. Сохранить узкое решение по тем моделям и тому срезу. Асимметрия существовала раньше; замер её не породил, но стал чрезмерным оправданием её сохранения |
|
||||
|
||||
Точные тела первых двух решений: `docs/archive/architecture/05-decisions-D39-arch-reset.md:154`, `:166`, `:200`, `:7`. Последнее переосмысление полисемии — `docs/architecture/05-decisions-log.md:2060`. Это конкретные основания пересмотреть степень уверенности и совместимость решений; они не доказывают, что все нынешние переводы хуже возможных.
|
||||
|
||||
**Полисемия проверена исполнением, бесплатно.** Каждый из двух подписанных смыслов отдельно загружается; вместе — отказ. Разнести их по двум файлам не помогает: общий проверяющий свода также отказывает. При входе ниже загрузчика настоящие `Materialize → Select → Render` сохраняют оба смысла. Контроль с непересекающимися окнами глав успешно загружается и выбирает по одному смыслу. Это подтверждает расхождение контрактов, не утечку запрещённого банка в реальный прогон. [Исходник пробы](31-harness-audit/polysemy_contract_probe_test.go.txt) сохраняется отдельно от кода продукта; воспроизведение — в конце.
|
||||
|
||||
Практический вывод для оркестратора: следующая проверка должна идти **от решения к его предпосылке и всем зависимым ограничениям**, а не только от свежего пака к его тестам. Для этих четырёх развилок уже названы и исходные основания, и текущие последствия. Нового общего процесса с десятками правил для этого не требуется.
|
||||
|
||||
**Что я исключил из списка «новых гипотез».**
|
||||
|
||||
| Идея | Где уже была | Почему не предлагаю как новую |
|
||||
|---|---|---|
|
||||
| Банк из оригинала, затем сильный прямой перевод | `START_PROMT.MD`, V6; `research/17-external-critique.md:61`; `research/30-arhitektura-otvet.md:110` | Есть постановка и несколько связанных сравнений. Полный вариант не закрыт, но идея старая |
|
||||
| Соседний контекст, lookahead, состояние сцены | `research/19-chunking-cohesion.md:191–224`; `experiments/15-segmentation-empirics.md:489` | Часть вариантов измерена, часть не исполнена. «Не измерено» не означает «никто не предлагал» |
|
||||
| Граф упоминаний, раздельные сущности/значения, адресные исходные свидетельства | `research/17-external-critique.md:41–63`; `research/30-arhitektura-otvet.md:271–279` | Это подходящий ответ на часть проблем нынешнего банка, но уже известное направление. Индекс сам по себе не меняет объект действия канона |
|
||||
| Плейсхолдеры имён и поздняя морфологическая подстановка | `research/15-voice-and-state.md:188`; `research/13-memory-bank-validation.md:133–136` | Уже названы и принцип, и условие безопасной подстановки. Формат с ID/падежами был бы уточнением, не новым подходом |
|
||||
| Предварительный смысловой разбор, Annotator, смысловой скелет | `experiments/09-pilot-protocol.md:155`; `research/29-harness-topology-survey.md:263` | Есть предшественники и отрицательный результат конкретной двухпроходки. Скрыть draft до первого прочтения — интересная отдельная интервенция, но не новое семейство архитектур |
|
||||
| Критик → локальный фиксер; patch/diff | V6; exp20/21; `research/30-arhitektura-otvet.md:104–110`; D39.117 | Конкретная дешёвая замена редактора не прошла. Отрицательный результат не закрывает все варианты, но повторять общий совет нельзя |
|
||||
| Отбирать фрагменты для дорогой редактуры | `experiments/21-role-topology.md:1039–1066` | Уже измеряли конкретные отборщики и получили слабую экономику |
|
||||
| Возражение к банку, рецензент спорных кластеров, quarantine | `research/17-external-critique.md:191–193`; `research/24-bank-arbitration.md:291–292`; D39.102/104 | Сам по себе «канал апелляции» — конкретизация старого намерения, а не новая гипотеза |
|
||||
| Разделить идентичность ответа и вердикта | `backend/docs/D15.2-content-addressed-resume-spec.md:1–15` | Давно спроектировано. В первом отчёте это была рекомендация приоритета, не новая идея |
|
||||
| Неизменяемый экспорт; принятие/отклонение правок человеком | `platform/internal/exports/exports.go:19–23`; `research/16-reader-ide-alignment.md:235–241` | Файлы экспорта уже неизменяемы; человеческое принятие давно обсуждалось |
|
||||
|
||||
Ниже — три конкретных изменения логики, полного эквивалента которых в проверенном корпусе я не нашёл. Это ограниченное утверждение о просмотренной истории, не доказательство мировой новизны. Ближайший предшественник и отличие указаны у каждого.
|
||||
|
||||
**Гипотеза 1. Выбирать канон вместе с его реализациями в книге. Мой первый выбор для прототипа.**
|
||||
|
||||
Сейчас процедура приблизительно такова: выбрать `dst` → закрепить его → независимо переделать затронутый текст. Предлагаю единицей принятия сделать **вариант общего решения вместе с согласованным набором его реализаций**. Новый перевод термина — кандидат до проверки того, что он делает с книгой.
|
||||
|
||||
Пример: название артефакта сначала понято буквально, поздняя сцена раскрыла второе значение, существенное для сюжета. Красиво перевести одно позднее употребление недостаточно. Нужно проверить, остаются ли ранние реплики правдивыми, сохраняется ли намёк и не раскрывается ли разгадка раньше времени.
|
||||
|
||||
Исполнимый поток:
|
||||
|
||||
1. Триггер — конкретное противоречие с исходником или предложенная правка пользователя. Не непрерывное «поищи ещё улучшения».
|
||||
2. Сформировать два кандидата: действующее решение и одну альтернативу. Каждый содержит область применимости, исходные свидетельства и перечень затронутых единиц. Для начала брать однозначно установленную сущность/семью; не выдавать строковый поиск за решённую кореференцию.
|
||||
3. Создать кандидатные версии только затронутых фрагментов под альтернативой. Обычный редактор сохраняется; обязательный diff-протокол не вводится. Старый текст остаётся доступным.
|
||||
4. Проверить **оба комплекта** по исходным употреблениям: ранним, поздним и тем, где новое решение может навредить. Первому прототипу достаточно независимой двуязычной проверки. Если такого проверяющего нет, автоматическое принятие смысловой ревизии пока не обосновано.
|
||||
5. Принять одной группой новую версию банкового решения и все необходимые редакторские результаты либо сохранить прежний комплект. Ошибка одного re-edit не должна оставлять читательскую редакцию наполовину на новом каноне.
|
||||
|
||||
Минимальный новый артефакт: `revision = base_revision + bank_delta + affected_units + candidate_hashes + decision`. Рабочие checkpoint остаются прежним механизмом оплаты; отдельный указатель определяет принятую редакцию. При изменении исходника или слиянии сущностей зависимые места нужно переопределить — совпадение прежнего списка не доказывает полноту. Пока их перечень не установлен, частичное переключение общего решения запрещено. Состояние «проверяется» не делает прежнюю ошибку правильной: известный дефект остаётся обозначенным и в старой редакции. Запрос текущего частичного результата по действующему экспортному контракту можно продолжать обслуживать отдельно.
|
||||
|
||||
**Содержательное отличие от старых идей:** keyword retranslation и семейный батчинг уже есть (`research/05-memory-glossary.md:82`; `research/24-bank-arbitration.md:396–410`). Но там сначала принимают термин, затем приводят текст к нему. Здесь **результат применения к тексту участвует в выборе самого термина**, а принятие относится ко всему связанному изменению. Неизменяемый EPUB-файл также не решает эту задачу: требуется состав принятой редакции до сборки файла.
|
||||
|
||||
Внешний источник механики — [Lehrer/Docent, §4, LCCO](https://ufal.mff.cuni.cz/pbml/108/art-garcia-espana-bonet-marquez-creus.pdf): несколько связанных лексических замен выполняются одной поисковой операцией. По одной они могут не улучшать оценку документа; вместе — улучшать. Перенос на пару «банковое решение + LLM-тексты» — **моя гипотеза**. Статья про старый en→es SMT и ограниченную оценку, не доказательство литературного zh→ru. Её функцию оценки и требование одинаковой лексики переносить не предлагаю.
|
||||
|
||||
**Что покупаем:** возможность исправить первичную интерпретацию по последствиям её применения; согласованность повторной редактуры; сохранение уже принятой работы при неудачном кандидате. Это не обещает автоматически узнать правильное значение.
|
||||
|
||||
**Цена и риск:** нужны зависимости между решением и текстами; неверно найденный набор употреблений даст неполное исправление; согласованная альтернатива тоже может быть ложной. Частая сущность затронет сотни глав — такой случай выходит за бюджет первой пробы. Начать с одного спорного решения, одной альтернативы и малого известного множества употреблений. Подписанное решение автоматически не менять.
|
||||
|
||||
**Как опровергнуть:** при одинаковых кандидатах и сопоставимом бюджете сравнить нынешний порядок «сначала выбрать банк» с выбором по комплектам. Для приписывания улучшения банку нужен также свежий re-edit под ПРЕЖНИМ банком: улучшить текст могла сама повторная редактура. Если комплект не позволяет принять лучшее смысловое решение, либо новые ошибки/цена съедают выигрыш, качественную гипотезу закрыть. Отдельная бесплатная проверка отказа: прервать одну связанную редактуру — принятая редакция не должна переключиться частично. Это проверяет только согласованность публикации.
|
||||
|
||||
**Гипотеза 2. Направлять исправление по результату ограниченной интервенции, а не по объяснению критика.**
|
||||
|
||||
Вместо схемы «критик назвал причину → исправляем названный узел» — диагностический режим для уже подтверждённого дорогого дефекта. У него три возможных подозреваемых: ложное банковое указание, якорение на черновике, неверное прочтение самого исходника.
|
||||
|
||||
Исполнимый протокол:
|
||||
|
||||
1. Зафиксировать исходный проблемный запрос и способ проверки конкретного дефекта. Например, кто именно отказался от предложения в исходнике; не общий балл художественности.
|
||||
2. Получить контрольные повторения прежнего запроса и ограниченные варианты с удалением **одного** основания: спорной банковой записи или всего черновика. Модель, исходный контекст и остальные параметры сохраняются. Контроль и вмешательства перемешиваются в одном временном блоке, чтобы изменение сервинга не было принято за эффект вмешательства.
|
||||
3. Сравнить частоту исправления конкретного дефекта и появления новых. Исчезновение ошибки в одном случайном ответе — не диагноз. Число повторов определяется допустимой ценой и необходимой различимостью; при нехватке данных результат `unknown`.
|
||||
4. Выход — рекомендация адресата ремонта с уликами. Устойчивое улучшение без банкового правила направляет случай к гипотезе 1; без черновика — к другому режиму генерации данного места. Ничего не меняет автоматически в подписанном каноне. Диагностические тексты сами по себе не публикуются.
|
||||
|
||||
**Что здесь новое относительно просмотренного:** абляции и контрфактуалы уже применялись на полигоне; source-grounded проверка давно предложена. Не нашёл в текущем маршруте и его постановках использования интервенции **после обнаружения дефекта для выбора того, что именно исправлять**. Это отличается от exp21 G: там отборщик заранее предсказывал, где редактура окупится; здесь проверяется чувствительность конкретного сбоя к конкретному входу.
|
||||
|
||||
**Что покупаем:** меньше бессмысленных повторных редактур под тем же неверным основанием. **Чего не покупаем:** строгого доказательства причинности одним вызовом или автоматической смысловой истины. Изменение длины запроса и взаимодействие нескольких оснований также могут влиять на ответ; вывод относится к вмешательству в данный запрос.
|
||||
|
||||
Если оба одиночных удаления не помогают, нельзя объявлять виноватым понимание источника: банк и draft могут независимо поддерживать одну ошибку. Нужен совместный контроль либо `unknown`. Удаление draft также меняет редакторскую задачу; положительный эффект показывает пригодность другого маршрута, но сам по себе не устанавливает психологический механизм якорения.
|
||||
|
||||
**Риск и предел:** дополнительные вызовы способны стоить дороже обычной прямой перегенерации. Поэтому это режим редкого сложного случая, не проход по каждой главе. **Как опровергнуть:** если при том же бюджете простая повторная редактура или прямой сильный перевод исправляют не меньше случаев и вносят не больше вреда, диагностический режим не нужен.
|
||||
|
||||
**Гипотеза 3. Деньги на завершение начатого результата должны быть недоступны для новых черновиков.**
|
||||
|
||||
Это решение проблемы порядка исполнения, а не средство улучшить литературность. Сейчас платформенный запас `k × expected + stepMax [+ bookOnce]` уже существует (`platform/internal/pricing/pricing.go:166–212`). Предлагать «добавить запас на редактора» заново было бы ошибкой. Но в движке он становится общим потолком: `Reserve` не различает деньги для новой черновой работы и деньги для завершения уже начатой.
|
||||
|
||||
Новый контракт допуска: перед началом порции определить бюджет её предусмотренного завершения — банковой работы, если нужна, редакторских вызовов и ограниченных повторов. Связать его с этой порцией; другие черновики не могут его занять. Новая порция допускается только из остатка после этих обязательств. Сначала завершается уже начатая работа; после settle неиспользованный запас освобождается. Этот фонд не прибавляет денег к пользовательскому потолку и не изображается фактической тратой.
|
||||
|
||||
Порция и её завершающий путь должны быть определены до допуска. Если фиксированная банковая фаза требует большего бюджета, чем доступно, резервирование само её не удешевляет: нужен меньший исполнимый заказ либо явный останов до покупки черновиков. Для максимального охвата всей книги может быть выбран прежний глобальный порядок, но его цена тогда становится осознанным выбором. Не следует молча сокращать уже обещанный пользователю объём.
|
||||
|
||||
**Новизна:** резерв отдельного вызова, повышенный платформенный холд и последовательный цикл всех стадий уже были. Не нашёл целевого обязательства, **зарезервированного до начала порции и защищённого от расходования другими порциями**. Это изменение admission-политики. Оно совместимо с разными расписаниями и не требует сразу строить граф всех зависимостей книги.
|
||||
|
||||
**Цена и риск:** меньшая параллельность, слишком осторожные оценки могут оставить деньги неиспользованными. Неизвестная фактическая стоимость или исчерпанный бюджет повторов всё ещё могут остановить работу. Гарантируется ограничение расходования назначенного фонда, а не хороший перевод и не безусловное завершение.
|
||||
|
||||
**Как опровергнуть:** при одинаковом общем потолке и заданных ответах/ценах подставного провайдера сравнить долю денег в незавершённых заготовках, число полных юнитов и задержку первого. Если на реалистичных распределениях нынешний запас уже снимает проблему либо потеря параллельности перевешивает пользу, новую политику не строить. Живой платный прогон для первого сравнения не нужен.
|
||||
|
||||
**Как бы я изменил ближайший курс.**
|
||||
|
||||
Начал бы с прототипа **совместного пересмотра одного канонного решения и его текстовых последствий**, используя существующие сохранённые материалы и редакторский путь. Это проверяет другую единицу принятия решения и непосредственно касается цели книги. Сначала установить, помогает ли она выбирать лучше; затем проектировать постоянное хранение принятых редакций. Диагностические интервенции — следующая, более рискованная ветка. Защищённый бюджет — самостоятельная альтернатива расписания, если при ограниченном бюджете важны законченные главы.
|
||||
|
||||
Есть старый, но необходимый долг перед расширением такого контура: канон относится к **сущности/значению в данном употреблении**, а не просто к одинаковым буквам. Его не выдаю новой идеей. При нынешнем запрете нельзя явно задать и проверить два одновременно действующих канона одной поверхности. Более сильная модель иногда разберётся сама, но не исправит этим контракт данных; различать нужно способность случайно получить хороший перевод и способность выразить и проверить требование.
|
||||
|
||||
Моё актуальное суждение: **реализация содержит полезные инженерные механизмы; переводческое ядро пока чрезмерно опирается на раннюю фиксацию строкового канона и одностороннее движение решения к финальному тексту.** Именно это я предлагаю поставить под изменение. Наличие тестов, принятых паков и объяснений в D-логе не даёт оснований заранее сохранять эту форму.
|
||||
|
||||
**Как проверялась история и где предел уверенности.** Повторно прочитаны собственный отчёт, стартовый бриф и относящиеся архитектурные документы; независимо разобраны код волн, банка, резервов, текущего export и версияции; сопоставлены research 05/13–24/29/30, старый `12-architecture-as-antipattern`, актуальная доводка и относящиеся эксперименты. Решения проверялись через индекс и тела D16, D39.102/104/117/144/158/198/205, а не через один пересказ. Поиск включал архивные решения, отчёты, промпты и документы платформы. Это не заявление о построчной вычитке каждого файла репозитория и не абсолютная гарантия отсутствия забытой формулировки.
|
||||
|
||||
Для проверки новизны сравнивался механизм, не только имя: поэтому placeholders, граф упоминаний, предразбор и апелляция исключены. Внешний поиск дополнительно дал [документный noisy-channel reranker](https://aclanthology.org/2020.tacl-1.23/): совместный выбор переводов по вероятности исходника при переводе и вероятности целевого документа. В корпусе его не нашёл, но в ближайшие рекомендации **не включаю**: это новостной zh→en, а доступный качественный вероятностный scorer нашей пары не установлен. Новизна сама по себе не оправдывает новую подсистему.
|
||||
|
||||
**Воспроизведение контракта полисемии.** В отдельной копии `backend` поместить приложенную пробу в `internal/membank/polysemy_contract_audit_test.go`. Из корня копии:
|
||||
|
||||
```sh
|
||||
GOCACHE=/tmp/textmachine-engine-logic-audit-gocache go test ./internal/membank -run '^(TestAuditPolysemyLoaderVersusRenderer|TestTheLawBlockGivesOneOrderPerSourceTerm)$' -count=1 -v
|
||||
```
|
||||
|
||||
Исполнено в `/tmp/textmachine-engine-logic-audit-09z7llyi`: обе проверки PASS. `memseed.go`, `memory.go`, `render_test.go` временной копии сверены SHA256 с рабочим деревом. Ключи, сеть и платные модели не используются. Сам тест не утверждает, что обе записи проходят штатный вход: он намеренно различает загрузчик и нижележащий renderer.
|
||||
Loading…
Add table
Reference in a new issue