Когда начинается роль инженера в проекте с векторной базой данных
Что проверяют
Видите ли вы, что векторная база это последний шаг решения, а работа инженера начинается раньше: с постановки задачи поиска и способа измерять его качество. Вопрос поведенческий, поэтому следом попросят пример: в какой момент вы подключились к проекту и что сделали первым.
Как отвечать
Сильный тезис: роль начинается, когда формулируют, что и как будут искать, то есть до выбора базы. Каркас стройте на своём проекте, по этапам:
- требования: какие запросы у пользователей, объём коллекции, частота обновлений, допустимая задержка, фильтры по метаданным и права доступа;
- оценка: размеченный набор пар «запрос, релевантный документ» и метрики
recall@k, MRR или nDCG. Без него все дальнейшие решения принимаются на глаз; - эмбеддинги и нарезка: модель под язык и домен, размер чанков и перекрытие, что делать с таблицами и длинными документами;
- индекс: метрика близости (косинус, скалярное произведение, L2), тип индекса (HNSW, IVF, квантизация) и компромисс между полнотой, задержкой и памятью;
- хранилище:
pgvector, если данные уже в PostgreSQL и объёмы умеренные, либо отдельная система вроде Qdrant, Milvus или Weaviate. Faiss при этом библиотека, а не база: хранения, фильтров и репликации в ней нет; - эксплуатация: гибридный поиск с BM25, переранжирование, мониторинг качества.
Назовите свои цифры: сколько векторов, какой recall получили, во сколько уложилась задержка p95. Если такого проекта не было, скажите прямо и опишите, с чего бы начали, опираясь на учебный проект или смежный опыт с поиском.
Где спотыкаются
Начинают ответ с выбора базы. Для интервьюера это сигнал, что вы решаете инструментом задачу, которую ещё не поставили.
Не упоминают оценочный набор. Без него нельзя доказать, что смена модели или параметров HNSW что-то улучшила.
Забывают про смену модели эмбеддингов. Векторы разных моделей несовместимы даже при одинаковой размерности, поэтому новая модель означает полную переиндексацию, и её надо закладывать в план заранее.