Ваша коллекция работает. Запросы возвращаются за несколько миллисекунд, результаты в основном верны, а отдел продукта продолжает пересылать вам те, что неверны. Вы открываете справочник по API поиска и находите точные определения для hnsw_ef, k для reciprocal rank fusion и квантованного пересемплирования. Определения верны. Но они все равно не говорят вам, какая настройка не работает на ваших данных.
Поэтому вы меняете одну настройку, перезапускаете запросы, и оценка меняется на 0,01. Улучшилась ли релевантность или те же запросы просто сработали иначе?
У каждой настройки есть правильное значение, и оно зависит от особенностей вашей коллекции, которые не видны по умолчанию. Эти особенности можно измерить. Мы провели такие измерения на пяти публичных наборах данных, от 5183 до 4,6 миллиона документов, и опубликовали результаты сегодня в пяти статьях. Вот проблема, которую решает каждая из них, и результат, которого мы не ожидали.
Пять статей рассматривают один путь запроса. Плотный и разреженный префетчинг извлекают кандидатов, слияние объединяет два списка в один рейтинг, а опциональный переранкер переупорядочивает его верхнюю часть.
Семь настроек, которые могут незаметно ухудшить ваш поиск
Начните с того, где вопрос об изменении на 0,01 получает свой ответ. Семь настроек коллекции могут ограничивать качество поиска независимо от того, что вы настраиваете дальше. Два примера: разреженный вектор без модификатора IDF не позволяет редким словам иметь больший вес, чем обычным, а средняя длина BM25, оставленная по умолчанию, неверно оценивает длину каждого документа. Ни то, ни другое не вызывает ошибку. Результаты просто становятся хуже.
Ваши метки также определяют, что вы можете измерить. В наших запусках 25 размеченных запросов оказалось недостаточно: шум был сильнее, чем любой прирост, полученный при настройке слияния. Статья «Что проверить перед настройкой коллекции Qdrant» охватывает все семь настроек и показывает, сколько размеченных запросов вам нужно, прежде чем следующим четырем проверкам можно будет доверять.
Извлечение сработало, ранжирование похоронило результат
Каждая поисковая система в конечном итоге сталкивается с этой жалобой: документ, который, как знает пользователь, существует, не появляется. Они искали по очевидным терминам, а он оказался на 40-м месте или вовсе не был найден. Либо извлечение пропустило его, либо ранжирование похоронило. Эти сбои требуют разных исправлений.
Очевидный шаг — извлекать больше. Увеличение количества извлеченных данных действительно помогло: повышение лимита кандидатов с 10 до 500 подняло максимально достижимую оценку на 0,28. Оценка, которую видели пользователи, изменилась максимум на 0,01, потому что ранжирование хоронило то, что извлечение уже нашло. Даже hnsw_ef, регулятор, к которому команды обращаются в первую очередь, изменил итоговую оценку максимум на 0,0022. Статья «Глубина кандидатов: сколько извлечения достаточно?» показывает проверку, которая отделяет пропущенное извлечение от похороненной релевантности, прежде чем вы потратите ресурсы на исправление не того параметра.
Одна константа изменила первый результат в 202 из 480 запросов
Гибридный поиск выполняет плотный и разреженный запросы, а затем объединяет два списка результатов с помощью reciprocal rank fusion. Одна константа, k, определяет, насколько это слияние отдает предпочтение документам с самым высоким рейтингом в каждом списке. В Qdrant по умолчанию установлено k=2, что делает ставку на первый выбор каждого списка. Переход на k=61 из оригинальной статьи изменил документ, занявший первое место, в 202 из 480 запросов на одном из наших наборов данных.
Это делает k достойным тестирования, но, возможно, он вам вовсе не нужен. DBSF, другой метод слияния в Qdrant, не требует параметров и превзошел стандартный RRF на трех из пяти наборов данных. Статья «Как настроить гибридный поиск в Qdrant» показывает, какой метод выбрать и какой показатель поможет подобрать k, если вы все же решите его настраивать.
Переранкер получил признание за настройку, которую мы пропустили
Вы добавляете кросс-энкодер, релевантность улучшается, и вы внедряете его. Это улучшение стоит одного прохода модели на каждого кандидата при каждом запросе, пока работает переранкер.
Прежде чем платить эту цену при каждом запросе, сначала настройте слияние. Часть того, что, по-видимому, дает переранкер, — это настройка слияния, которую вы пропустили. Лучший из четырех переранкеров превзошел стандартное слияние Qdrant на всех пяти наборах данных, но при настроенном слиянии большая часть этого прироста исчезла, а один выигрыш превратился в проигрыш. Статья «Стоит ли использовать переранкер?» показывает дешевый тест, который подскажет, когда модель оправдывает свою задержку.
Запрос, который стал в 10 раз медленнее за выходные
Ваш p95 выглядел нормально в пятницу. Коллекция выросла за выходные. В понедельник тот же запрос выполняется в десять раз дольше, без ошибок и без изменений конфигурации.
Виновник — пересчет (rescoring). Квантование хранит сжатую копию ваших векторов в оперативной памяти и перечитывает оригиналы, чтобы исправить ошибку сжатия. Пока оригиналы помещаются в память, это перечитывание почти бесплатно. Как только они перестают помещаться, система обращается к диску: тот же запрос замедлился с 4,3 мс до 43,4 мс.
Поэтому измеряйте квантование с тем лимитом памяти, который вы используете при развертывании, потому что машина со свободной оперативной памятью может скрыть стоимость чтения с диска. И дважды подумайте, прежде чем отключать его: без пересчета плотный этап находил только шесть из десяти истинных ближайших соседей. Статья «Когда ваша коллекция перестает помещаться в RAM» содержит протокол выбора между скоростью и полнотой (recall), а также сигнал, который предупредит вас раньше, чем это сделает p95.
Начните с проблемы, которая у вас есть
Каждая статья отвечает на один из этих вопросов:
- Вы изменили настройку и не можете сказать, помогло ли это: «Что проверить перед настройкой коллекции Qdrant»
- Документ, который, как вы знаете, существует, возвращается похороненным или отсутствует: «Глубина кандидатов: сколько извлечения достаточно?»
- Вы используете гибридный поиск с настройками слияния по умолчанию: «Как настроить гибридный поиск в Qdrant»
- Вы решаете, оправдает ли переранкер свою задержку: «Стоит ли использовать переранкер?»
- Задержка подскочила после роста коллекции: «Когда ваша коллекция перестает помещаться в RAM»
Если подходит больше одного, начните с первого. Он создает набор размеченных запросов, на которых работают остальные четыре проверки, используя запросы, которые отдел продукта продолжает пересылать вам в качестве исходного материала. Выполните проверки, и настройка перестанет быть гаданием.
