84 lines
4.4 KiB
Markdown
84 lines
4.4 KiB
Markdown
# 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 — следующий слой поверх той же истории.
|