А с векторным-то поиском что не так?

Обсудили, как llm-as-a-judge стал антипаттерном, который непрозрачно прячет под собой большую сложность, теперь давайте поговорим про векторный/семантический поиск.

Если смотреть на эту технику абстрактно - все с ней ок. Задача построения эмбедов снижением размеренности пространства с нами давно, олды из NLP вспомнят LDA/LSA, олды (и не очень) из рексиса матричную факторизацию. Первый ренессанс в широких инженерных массах у векторного поиска случился в середине десятых, когда все распробовали word2vec. Это действительно был очень свежий и классный кусок теха: unsupervised метод, дешевый в обучении (а чаще сразу предобученный) и инференсе, который укладывает семантически близкие слова близко друг к другу в пространстве эмбедов. Обещал с ноги закрыть проблему синонимов-парафразов, морфологии (в фасттексте), а с небольшими допилками еще и мультиязычности. Именно тогда если помните был первый бум чатботов, алексы и т д. Как раз потому что это была простая в реализации и доступная не-млщику технология семантичнского поиска.

Потом правда наступило похмелье: оказалось, что на многих задачах этот метод не обгонял bm25. Непонятно как дружить со структурированными текстами. Он либо работает как надо сразу из коробки, либо получить желаемые свойства очень сложно (единственная нормальная ручка - строить модель поверх). Он не решает вопрос замешивания не-текстовых фичей. Короче в серьезных продуктах все остались на классическом retrieve-rerank, где векторный поиск генерит кандидатов и используется фичей в ранжирование. Ну или стали инициализировать ими сетки для трейна на задачу.

Проходит чуть меньше 10 лет и про векторный поиск опять начинают говорить «все и их мамы». В этот раз в контексте RAG систем и context engineering’a LLM. С тех пор эмбеддинги у нас научились строить поверх предложений, а не слов. Считаются они трансформером, в не лежат в словаре. Но суть та же: unsupervised метод как-то сближает в среднем похожие по смыслу предложения и расталкивает разные.

А болячки все те же. Но в этот раз на них посмотрели не млщики, а армия креативных SWE и сбросив с парахода современности задачу IR начала сначала:
- 50 оттенков чанкинга
- а давайте к чанкам метаданные приписывать еще текстом
- агент, который через MCP сам себе собирает нужный контекст
- надо агенту дать почитать заголовки документов и тулу которой он может достать контент того, что он считает нужным
- mcp уже пробовали?
- диприсеч!
- перепишем все базы знаний, чтоб агент в них разобрался
- и конечно же каждый из методов оборачиваем в фреймворк, который несовместим с 15 уже имеющимися

Ну и это ожидаемо: даже очень классные SWE как правило не привиты дата-дривен культурой и базовой насмотренностью в области IR в той же степени, что и MLE (хотя справедливости ради и многие MLE тоже). Из-за этого в руках оказывается любимый молоток и начинается инвестиция усилий в инженерные решения, вместо инвестиций в данные (эвалы, разметки на руткоз, разметки для обучения). Это еще и полируется сверху llm-as-a-judge, и этот инженерный урборос катится куда-то в сторону от простого решения.

Что с этим всем делать? Во-первых изучать мл-систем дизайн. В арсенале инженера должно быть много инструментов решения типовой проблемы (а поиском мы уже пол века занимаемся). Во-вторых инженерные решения должны опираться на данные. Хорошо бы распричинить ошибки вашей системы на около-прод распределении, и для начала понять, а почему текущий подход не справляется? Это натолкнет на наиболее дешевое решение. Да это гораздо трудозатратнее, чем просто воткнуть модную блестящую штуку себе в пайплан, но зато и успех намного вероятнее в таком подходе.