Коллекция отвечает за миллисекунды, большинство результатов выглядит разумно, но пользователи регулярно находят промахи. В такой ситуации команда обычно крутит hnsw_ef, увеличивает число кандидатов или добавляет rerанкер. Свежая методика Qdrant показывает, почему этот ритуал часто повышает счет за инфраструктуру, а не качество поиска: сначала нужно отделить провал retrieval от провала ranking и убедиться, что разница вообще измерима.
Сначала тестовый контур, потом ручки
В блоге Qdrant описаны измерения на пяти публичных наборах размером от 5 183 до 4,6 млн документов. Проверялся один поисковый путь: dense- и sparse-prefetch собирают кандидатов, fusion объединяет списки, а необязательный rerанкер меняет порядок верхних результатов.
Главная практическая мысль не привязана к конкретной ручке Qdrant. До экспериментов нужен набор размеченных запросов, на котором можно сравнить качество до и после изменения. Сырьем авторы предлагают сделать те самые запросы, которые продуктовая команда пересылает разработчикам после жалоб пользователей.
В тестах Qdrant 25 размеченных запросов оказалось недостаточно: шум был шире, чем выигрыш от настройки fusion. Это не универсальный минимальный размер выборки, а полезная проверка здравого смысла. Если изменение оценки на 0,01 укладывается в разброс теста, объявлять победу рано.
До тюнинга Qdrant также советует проверить семь настроек коллекции, способных ограничить качество всей дальнейшей цепочки. Например, sparse-вектор без IDF modifier не дает редким словам больший вес, а оставленная по умолчанию средняя длина BM25 неверно оценивает длину документов. Ошибки при этом не возникает. Поиск просто работает хуже.
Дорогая проблема может оказаться не проблемой retrieval
Когда нужный документ не появляется наверху, есть два разных сценария: retrieval его не нашел или ranking нашел, но закопал. Платить за исправление до диагностики рискованно.
В измерениях Qdrant увеличение лимита кандидатов с 10 до 500 поднимало лучший достижимый score на величину до 0,28. Но итоговая оценка, которую видел пользователь, менялась максимум на 0,01, потому что ranking продолжал прятать уже найденные документы. Настройка hnsw_ef, за которую команды часто хватаются первой, сдвигала финальный score не более чем на 0,0022.
Для оператора RAG-системы вывод неприятный, но экономный: больше кандидатов и более агрессивный обход индекса не гарантируют лучшую выдачу. Они гарантируют дополнительную работу. Сначала стоит измерить recall на этапе retrieval, затем качество итогового ранжирования. Иначе сервер честно ищет больше документов, чтобы следующий этап так же честно поставил нужный на сороковое место.
Та же логика работает в hybrid search. В Qdrant значение k для reciprocal rank fusion по умолчанию равно 2, поэтому слияние сильно доверяет первым результатам каждого списка. Переход к k=61 из исходной статьи изменил документ на первой позиции для 202 из 480 запросов на одном наборе. Параметр явно влияет на продуктовый результат, но это еще не аргумент в пользу конкретного значения. Более того, fusion-метод DBSF без настраиваемых параметров обошел дефолтный RRF на трех из пяти наборов.
Реранкер и RAM нужно заставить доказать свою цену
Cross-encoder добавляет проход модели по каждому кандидату каждого запроса. По данным Qdrant, лучший из четырех rerанкеров обошел стандартный fusion на всех пяти наборах. После настройки fusion большая часть выигрыша исчезла, а в одном случае преимущество превратилось в проигрыш.
Значит, rerанкер стоит подключать не как обязательный слой современной архитектуры, а только после сравнения с настроенным fusion на тех же размеченных запросах. Его добавочная точность должна окупать добавочную задержку. Иначе модель продает команде вычисления, маскируя пропущенную настройку более дешевого этапа.
Отдельный контур нужен для quantization. Она хранит сжатую копию векторов в RAM, а при rescoring перечитывает оригиналы. Пока оригиналы помещались в память, перечитывание почти ничего не стоило. После выхода за предел RAM тот же запрос в тесте Qdrant замедлился с 4,3 до 43,4 мс. Отключать rescoring вслепую тоже нельзя: без него dense-этап находил только шесть из десяти истинных ближайших соседей.
Методика Qdrant отделяется от маркетинга ровно там, где требует сравнивать альтернативы по измерениям, а не верить дефолтам самого Qdrant. Но результаты пяти публичных наборов нельзя переносить в прод как готовый конфиг. Их ценность в порядке эксперимента: зафиксировать размеченные запросы, измерить retrieval и ranking отдельно, прогнать fusion и rerанкер, затем повторить latency-тест у реального лимита памяти.
Маркер успеха простой: после следующего изменения команда должна показать не одну красивую среднюю оценку, а одновременно recall retrieval, качество финального списка, p95 и потребление памяти на неизменном наборе запросов. Если таких четырех чисел нет, это пока не тюнинг. Это перебор ручек с бюджетом компании.