Кто находит нужное письмо и тред точнее и быстрее — BM25+kNN на OpenSearch или косинус+tsvector на Postgres. Одни и те же эмбеддинги (GigaEmbeddings, dim=2048), один и тот же чанкинг, честная матрица 2 бэкенда × 3 режима × 2 варианта.
Авто-вывод по всей матрице бенчмарка, 220 golden-запросов × 3 повтора на конфигурацию.
Доля запросов, где нужное письмо / нужный тред попал в топ-10.
Конкретные golden-запросы из корпуса и то, что на них случилось в бенчмарке — не усреднённые проценты, а реальный запрос → реальный результат конкретной конфигурации.
2 бэкенда × 3 режима (dense / lexical / hybrid) × 2 варианта (без / с summary-векторами треда). ★ — лучший результат в столбце.
220 запросов поровну по 4 типам: смысловой перефраз (semantic), точная сущность вроде номера договора (lexical), вопрос про исход треда без явных сущностей (thread-level), запрос с SQL/DSL-фильтром по отправителю или дате (filtered).
Медиана и p95 по 220 запросам × 3 повтора, логарифмическая шкала — диапазон от 0.4 мс до 50 мс.
На dense и hybrid у обоих бэкендов ThreadHit@10 и так близок к 1.0 — добавить нечего. Но у pgvector lexical summary-вектор чинит главную слабость: короткие треды без общей лексики между письмами и запросом.
pgvector · lexical · thread-level: 0.382 → 0.709 (+0.327)
Среднее по всем режимам и бэкендам: Δ +0.055 — summary-векторы чуть помогают и нигде не вредят.
По 3 случайных примера на тип из 220 сгенерированных запросов, каждый привязан к конкретному письму или треду в корпусе.