doc: ответ Opus раунд 2 — provenance, confidence, temporal UI

History/opus-answer-2.md

@@ -0,0 +1,83 @@
+# Opus 4.8 — Раунд 2: Практические ответы для реального проекта
+
+**Дата:** 2026-06-23
+
+---
+
+## Вопрос 1: Одна идея с максимальным преимуществом
+
+**Provenance с кликабельной трассировкой до исходного текста.**
+
+Юрист подписывается под результатом. «Добавилась услуга X за 15000» без источника — бесполезно. «Добавилась услуга X ← допник №3, п.2.4, вот абзац» → проверка за 2 секунды → реальная экономия.
+
+**Механика:** каждая op содержит `source_quote` (точная цитата из документа). Клик по строке → показать исходный абзац в документе.
+
+---
+
+## Вопрос 2: Self-consistency vs logprobs
+
+**N=1 + self-reported confidence. Не logprobs.**
+
+Причины:
+- logprobs на JSON шумные — не отражают уверенность в смысле
+- Модель сама возвращает `confidence: 0.0-1.0` — ноль инфраструктуры
+- Self-consistency 3 прогона НЕ утраивает время: прогоны одного файла независимы → параллельно ~80с, не 240с
+
+**Оптимальный гибрид:** N=1 по умолчанию. Для ops с `confidence < 0.7` → выборочный повторный прогон. Низко-confidence → в очередь на ручную проверку.
+
+---
+
+## Вопрос 3: Минимальный двухслойный лог
+
+**Слой 1 уже есть — таблица `documents`** (original_bytes + elements_json = сырые факты).
+
+Минимальное: добавить в `spec_events` колонку **`source_document_id`** (FK → documents).
+
+Не нужно `event_type`, не нужно `parent_event_id`. Одна FK-колонка даёт:
+- Двухслойное разделение
+- Provenance-костяк
+- Возможность ре-интерпретации новыми моделями
+
+---
+
+## Вопрос 4: Эмбеддинги vs NFKC
+
+**NFKC покрывает ~90-95%. Эмбеддинги преждевременны.**
+
+NFKC ловит типографику (тире, пробелы, кавычки). Эмбеддинги нужны только для семантического перефраза — но в домене облачного провайдера допники копируют названия дословно. Плюс после подачи LLM `spec_current` с готовыми ID проблема матчинга почти исчезает.
+
+**Рекомендация:** NFKC достаточно. pgvector добавлять только при доказанных промахах.
+
+---
+
+## Вопрос 5: Temporal UI
+
+**Шаговый таймлайн:** `Договор → Допник1 → Допник2 → Допник3`.
+
+Клик на узел = спецификация на этот момент.
+
+**Две ручки выбора (from/to):** diff-таблица между версиями.
+
+**Визуализация:** 🟢 добавлено / 🔴 удалено / 🟡 изменено с inline old→new.
+
+**Каждая строка кликабельна** → provenance (исходный абзац).
+
+**Два режима:** «Итог» (последняя vs база) и «Пошагово» (дельта каждого допника).
+
+---
+
+## Вопрос 6: Provenance MVP — колонки
+
+Три колонки в `spec_events`:
+
+1. **`source_document_id`** FK → documents — самая важная. Костяк всего.
+2. **`prompt_version`** TEXT — какая версия промпта.
+3. **`raw_llm_response`** JSONB — полный ответ модели.
+
+Поле `source_quote` — внутри op (в raw_llm_response), не отдельная колонка.
+
+---
+
+## Сквозная логика
+
+`source_document_id` + `source_quote` от LLM закрывают provenance, двухслойность и трассировку одновременно. Самый дешёвый и конкурентный ход. Temporal UI — следующий слой поверх той же истории.