pgvector отказывает на 3072 измерениях: как это стало удачей

Работаю с документами большого объема, генерирую их по шаблону заказчика из технических спецификаций. Нужна база знаний внутри документа, чтобы рассказывать детали из разных разделов без ошибок. Выбрал OpenAI text-embedding-3-large: хорошие эмбеддинги, 3072 измерения, положил в pgvector.

Первый же тест на полном документе упал с ошибкой: ANN-индекс ivfflat не может строиться на векторах свыше 2000 измерений. Ладно, подумал я, либо обрезать до 2000 и потерять качество, либо перейти на другую БД.

Потом понял: можно просто не индексировать. Косинусный поиск через полный перебор работает на любой размерности, цена вычисления растет линейно. Вынес индекс из миграции, в коде указал EMBED_INDEX=none, и обратимо решил задачу без ломания контракта: поле остается vector(3072), база его принимает, тесты зеленые.

Очень быстро? Нет. Но рост данных покажет, когда перебор станет узким местом. Сейчас это оплачивается вычислением, а не архитектурой. Когда узкое место переместится выше, переберу поэтапно: quantization, halfvec или просто другой провайдер вектор-базы. А пока система работает, и я знаю, в какой момент ее перестраивать.

#pgvector #PostgreSQL #векторныебазы #RAG #работающее_а_не_идеальное #генерациядокументов #Python #реальные_требования