Data engineering
Vector search: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту vector search — recall vs latency, HNSW vs IVF-PQ, метрики расстояния, post-filtering и тихий провал recall.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь, глядя на RAG-пайплайн, возвращающий десять ранжированных строк, быстро, без ошибок — и не те десять.
Цель
Убедись, что связываешь embedding, выбор ANN-индекса, треугольник recall–latency–memory, метрики расстояния и production-ловушки — тот синтез, к которому вёл урок.
Викторина
Completed
RAG-поиск возвращает десять ранжированных строк за 2 мс без ошибок, но поддержка сообщает, что бот 'не находит' документы, которые явно есть. Самая вероятная причина и как её подтвердить?
Heads-up Она возвращает все десять строк за 2 мс без ошибок — БД здорова. Низкий recall невидим: по числу строк и latency он выглядит как высокий.
Heads-up Запросы успешны за 2 мс; симптом — неверные результаты, а не медленные или упавшие. Это указывает на recall, а не на вызов embedding.
Heads-up Проблема не в throughput, а в корректности. Реплицирование индекса с низким recall лишь умножает неверные ответы.
Викторина
Completed
RAG-сервис на ~5M чанков с непрерывным приёмом данных, высокими требованиями к recall и запасом RAM. Какой индекс выбрать по умолчанию и почему?
Heads-up Центроиды IVF фиксируются при построении, поэтому непрерывный приём данных постепенно сносит recall, пока не сделаешь reindex. С запасом RAM и требованием высокого recall это выбор дрейфующего индекса ради экономии памяти, которая тебе не нужна.
Heads-up PQ нужен, когда корпус вообще не влезает в RAM (100M+). На ~5M с запасом RAM ты платишь потерей recall от квантизации за сжатие, которое не требуется.
Heads-up Точный kNN даёт recall 1.0, но это O(N·d); на 5M на 1536 измерений каждый запрос — миллиарды умножений-сложений, поэтому p99 неотгружаем. Это offline-baseline, а не путь обслуживания.
Викторина
Completed
Поднятие hnsw.ef_search со 100 до 500 двигает recall с ~85% до ~98%, но latency с ~1 мс до ~5 мс. Как это читать senior-инженеру?
Heads-up Ни один ANN-индекс на этапе запроса не улучшает recall и latency одновременно; они торгуются вдоль ef_search. Эти числа — нормальная форма ручки.
Heads-up M — это build-time ручка, влияющая на плотность графа и память; она не заменяет ef_search. Перестройка гораздо дороже, чем поворот рантайм-ручки до цели.
Heads-up У IVF тот же компромисс recall/latency через probes, плюс дрейф центроидов. Смена индекса не выводит из треугольника — любой ANN торгует recall за скорость.
Викторина
Completed
Команда хранит нормализованные embedding и спорит про cosine similarity vs внутреннее (dot) произведение. Что верно?
Heads-up Cosine — это dot product, делённый на длины. На уже нормализованных векторах длины равны 1, поэтому оба дают идентичное ранжирование — cosine лишь добавляет лишнюю работу.
Heads-up L2 ранжирует иначе, чем cosine, если векторы не нормализованы, а метрика, под которую embedding не обучались, ухудшает ранжирование. Метрика должна совпадать с моделью, а не быть L2 по умолчанию.
Heads-up Метрика задаёт, что значит 'ближайший', и меняет ранжирование, если векторы не нормализованы. Неверный выбор под модель тихо ухудшает релевантность.
Викторина
Completed
Поиск с областью видимости тенанта добавляет WHERE tenant_id = ? поверх HNSW-запроса, и для маленьких тенантов recall резко падает. Почему и как чинить?
Heads-up B-tree по tenant_id ускоряет фильтр, но не меняет того, что ANN-кандидаты собираются до применения фильтра — обвал recall из-за порядка post-filtering, а не скорости фильтра.
Heads-up Даже при достатке подходящих документов post-filtering выбрасывает большинство ef_search кандидатов, потому что они принадлежат другим тенантам. Проблема в порядке, а не в размере корпуса.
Heads-up Метрика тут ни при чём. Потеря recall — оттого, что фильтр применяется после того, как обход графа уже сузился до ef_search кандидатов.
Викторина
Completed
Пользователи ищут точную строку ошибки 'ECONNREFUSED', а чистый vector search хоронит нужный документ под смутно-связанными абзацами. Лучший фикс?
Heads-up Больше кандидатов того же рода не помогает — потребность лексическая, а embedding размазывают точный токен вроде кода ошибки в 'семантически близкое'. ef_search настраивает vector recall, а не точность совпадения токена.
Heads-up Бо́льшая модель всё равно измеряет семантическую близость; она не даёт точности по токену. Коды ошибок, SKU и идентификаторы — это keyword-потребность, которую закрывает BM25.
Heads-up Выбор метрики чуть двигает ранжирование, но никогда не даёт лексической точности. Vector search лишён точного совпадения независимо от метрики; hybrid добавляет keyword-ногу, у которой оно есть.
Итог
Сквозная линия — один треугольник recall, latency, memory — и одна привычка: провалы recall тихие. Пул кандидатов (ef_search / probes) задаёт recall vs latency, семейство индекса задаёт память и дрейф (HNSW для изменяющихся данных, IVFFlat для статики, IVF-PQ когда не влезает в RAM), метрика должна совпадать с тем, как обучались embedding, post-filtering ломает селективные фильтры (используй iterative scan), а потребность в точных токенах требует hybrid BM25 + vector с rank fusion. Прежде всего — измеряй recall@k против точного baseline, иначе летишь вслепую.