664 тысячи книг и десятки агентов: почему метрики в больших поисковиках нельзя доверять

# 664 тысячи книг и десятки агентов: почему метрики в больших поисковиках нельзя доверять

Проект по созданию собственной библиотеки аудиокниг, включающей более 664 тысяч записей, казался задачей стандартной сложности: взять фрагмент аудио, распознать его текст и найти соответствующую книгу. На первый взгляд, достаточно просто прогнать текст через модели распознавания речи (например, Whisper) и использовать поиск по ключевым словам. Однако на практике выяснилось, что создание работающего индекса — это лишь половина проблемы. Гораздо труднее и важнее понять, насколько точно этот индекс работает.

Кризис «правильных» данных

Главная препятствие на пути создания надежной системы — отсутствие достоверного датасета для тестирования. Традиционно качество поиска оценивается на наборах данных, где заранее известны правильные ответы. В случае с аудиокнигами и большими корпусами книг такая разметка невозможна вручную из-за огромных объемов информации, а автоматическая генерация данных часто содержит системные ошибки.

Автор проекта столкнулся с проблемой дубликатов: часто автор и название совпадают, но книги различаются переводом, изданием или содержанием. Попытки использовать внешние метаданные для автоматической верификации привели к тому, что созданные «датасеты» оказались не независимыми. Например, проверка через аудиокниги и через текстовые источники в итоге опиралась на одни и те же ошибочные таблицы, что искажало картину надежности.

*Ключевой вывод автора: название датасета часто не отражает его реального состава. Если неизвестен метод построения выборки, ее название имеет минимальную ценность.*

Технические вызовы и поиск по вложенности

Для реализации поиска была разработана система на основе блочного MinHash и проверки цепочек (chaining). Классический подход MinHash с использованием шинглов (последовательностей слов) не справлялся со случаями вложенности, когда один роман целиком находится внутри собрания сочинений. Жаккардово расстояние в таких случаях давало неверные результаты.

Решение пришло в виде комбинированного подхода: расчет отпечатков по блокам текста, содержащим минимумы, с последующей обязательной проверкой наличия связного куска текста. Это позволило снизить количество ложных срабатываний с десятков процентов до долей процента, сделав систему пригодной для дальнейшей разработки.

Как работает поиск по блокам 1. Текст книги разбивается на блоки по 300 шинглов. 2. Для каждого блока вычисляются локальные минимумы (отпечаток). 3. Кандидат считается найденным только если в нем обнаружен связный фрагмент текста (цепочка), а не просто набор случайно совпавших слов.

Ложный ноль и скрытые ошибки

Одной из самых распространенных ошибок в разработке поисковых систем является вера в «красивый ноль» ошибок. На малых выборках (например, 320 запросов) может не найден ни одного ложного срабатывания, что интерпретируется как идеальная точность. Однако статистика показывает, что такое отсутствие ошибок на малой выборке статистически значимо лишь для того, что процент ошибок меньше 0,94%, а не равен нулю.

Более того, автор выявил критическую ошибку в логике тестирования: система считала кандидатов, тексты которых не загрузились в базу проверок, как «проверенные и отвергнутые». В реальности 85,3% кандидатов не прошли проверку вовсе из-за технической ошибки в выборе базы данных. Это привело к завышению показателей надежности: «0 ложных на 4060 запросах» на самом деле означало проверку лишь около 232 реальных кандидатов.

Что измеряет и что скрывает метрика После исправления ошибки и пересчета на полный объем данных картина изменилась: выявлено 3 ложных срабатывания из 4060 запросов (0,074%). На специально подобранных похожих книгах показатель вырос до 0,25–0,35%. Эти цифры гораздо честнее отражают реальную ситуацию, чем обещанные «нулевые» показатели.

Проблема независимости тестов

Другим важным открытием стало непонимание природы независимости испытаний в голосовании по отрывкам. Автор ожидал, что проверка 10 различных фрагментов одной аудиокниги будет равна 10 независимым тестам. Однако оказалось, что если книга не найдена по одному отрывку, она, скорее всего, не будет найдена и по другим. 19,6% аудиокниг провалили все 10 проверенных отрывков одновременно, что свидетельствует о системном сбое на уровне целого произведения, а не о случайных ошибках алгоритма.

Разница между «поиском книги» и «поиском текста» Схема «запрос → единственный правильный ID» не применима к задачам поиска больших текстовых сущностей. Если искомая книга содержится в сборнике, то как в отдельный файл, так и в сборник следует считать верными результатами. При жестком требовании единственного ID точность системы могла бы показаться низкой (около 59%), в то время как фактически книга была найдена в 99% случаев, просто в разном контексте.

Заключение: работающий прототип vs доказанная метрика

В ходе разработки были получены две системы: одна выполняет поиск по огромному корпусу, а вторая пытается оценить качество этого поиска. На данный момент первая система уже готова к работе, но вторая находится в стадии создания.

Главный вывод статьи заключается в том, что наличие красивых графиков и утверждений о превосходстве одного алгоритма над другим без надежной метрики качества бессмысленны. Без понимания того, какие именно данные участвуют в тестировании и как они были получены, любые количественные показатели остаются лишь словами.

Разработка эталонной разметки для таких масштабов — задача настолько сложная и интересная, что она требует создания отдельной системы. Пока этот фундамент не заложен, любой отчет о точности поиска остается предварительным и требует перепроверки.