Очередь review, findings, lineage

Три инструмента контроля качества базы знаний. Все три — для админа, доступны в /manage/ak.

Pending review queue

📍 /manage/ak/pending

Все новые наблюдения сначала попадают в очередь pending — ak_pending_observations. Это «карантин» перед публикацией.

Откуда они берутся:

1. Агент сам через record_observation
2. Conversation extractor — еженедельно из чатов
3. API-наблюдения и триггеры
4. Ручное обучение из /manage/ak/training

Что показывает список:

• content — текст наблюдения
• kind / visibility / source — атрибуты для фильтра
• confidence — уверенность LLM или агента
• status — queued / processing / failed

Что можно сделать:

• Approve → конфликт-резолвер обработает прямо сейчас (через minutes)
• Reject + причина → запись помечается resolved, чанк не создаётся

💡 Большинство наблюдений из manual_ingest помечены auto_approved=true и проходят мимо очереди — резолвер пишет их сразу как confirmed. Они появляются в pending только если резолвер не успел отработать.

Findings (проверки качества)

📍 /manage/ak/findings

Это диагностические проверки, которые система автоматически прогоняет:

Каждый finding имеет:

• severity — low / medium / high
• detected_at — когда нашли
• dismissed_at — NULL пока не разобрались
• resolution — что решили

Что делать:

• Прочитать описание
• Открыть связанный чанк
• Если факт всё ещё верный — нажать Dismiss с пояснением
• Если факт устарел — отредактировать (/manage/ak/chunks/{id}) или перевести в archived

⚠️ Не игнорируйте high-findings — они часто маркируют чанки, у которых отвалились исходники, а значит, агент может цитировать выдумку.

Lineage (граф происхождения)

📍 /manage/ak/lineage — индекс; /manage/ak/lineage/{id} — граф конкретного чанка

Lineage — это родословная чанка. Когда compressor сжимает несколько похожих наблюдений в один canonical lesson, новый чанк помнит:

• Из каких source-чанков собрался (derived_from)
• Какие конкретные предложения из source'ов он использовал (provenance)

Граф показывает: target chunk ← edges ← source chunks. Полезно когда:

• Хочется проверить, не упрощён ли смысл слишком сильно
• Нужно понять, откуда взялся «свежий» factoid в базе
• Расследование, почему агент сказал X (cite trace)

Coverage gaps (пробелы)

📍 /manage/ak/gaps

Когда агент НЕ нашёл подходящего чанка на пользовательский запрос — это записывается в ak_coverage_gaps. Со временем накапливается список тем «надо бы написать».

Каждый gap имеет статус:

• open — не разобрали
• in_progress — пишем
• resolved — закрыли (либо написали чанк, либо нашли existing)
• dismissed — нерелевантно

Удобно открывать раздел раз в неделю, выбирать гэп, и через «Обучение» заливать материал по теме.

Dedup clusters

📍 /manage/ak/dedup

История работы dedup-кластеризатора — какие чанки система склеила за дубли. Каждый event:

• archived chunk (тот, который убрали)
• kept chunk (который оставили)
• similarity (cosine 0..1)

Если видите ложное склеивание (similarity типа 0.78, но факты разные) — это сигнал ослабить порог dedup'а или внести правило.

Связь между всеми четырьмя

record_observation / extractor / manual_ingest
        ↓
   ┌─ pending queue ─────────────────────────────┐
   │  (admin может approve/reject вручную)        │
   └─────────────────────────────────────────────┘
        ↓
   conflict_resolver  (cosine ≥ 0.75 → NOOP/UPDATE/DELETE/ADD)
        ↓
   ak_chunks (draft / confirmed / archived / static)
        │
        ├─ findings  ← периодически: source_check, lineage_assessment
        ├─ dedup     ← периодически: cluster + merge near-duplicates
        └─ promoter  ← daily: draft → confirmed по evidence + age

Чтобы поддерживать базу в порядке — раз в неделю пробегайтесь:

1. /manage/ak (дашборд) — смотрим counts, нет ли всплесков failed
2. /manage/ak/findings?include_dismissed=false — разбираем high severity
3. /manage/ak/gaps — берём один gap, идём в «Обучение»
4. /manage/ak/dedup — проверяем, не было ли неверных слияний