Здравствуйте, Артём, Вы писали:

Аё>Вопрос к nuzhny — скажем, есть таблица parts (например, бп, видеокарты, материнки и т.п.) у каждой позиции есть короткое поле description. карта/бп/материнка подбирается к недособранному компу (это контекст) и должно абсолютно 100% подходить. Процесс "подходит/неподходит" на данный момент прошит программно. Есть поиск по подстроке description, программно, реализован 100500 лет назад.

Аё>Вопрос 1 — если в пре-процессить поле description в вектор и доложить рядом файлик sqlite-vector, а потом при поиске по description, искать вектор nearest neighbor вместо подстроки- это имеет право на жизнь? Или полный бред?
Аё>Вопрос 2 — если добавить в вектор также как-то информацию об к какому набору/платформе подходит эта деталь, а потом опционально при поиске по description добавлять какие-то флаги о "ищи внутри набора Х"- чтобы искало "в общем" и опционально "сузить до подходящих к Х" это имеет право на жизнь?

Аё>https://www.sqlite.ai/sqlite-vector

Аё>Применительно к собственно ручному поиску юзером, и к поиску агентом (llm). Если агент (скажем, модель крутится в ollama) — нужно ему указать (mcp) Tool или возможны какие-то низкоуровневые интерфейсы для RAG?

Мне кажется это плохая идея. Точность поиска сильно размажется, будет бред.
Векторный поиск ищет семантическую близость, но "GTX 1660 Ti" и "GTX 1650" семантически очень близки, хотя это разные карты с разной совместимостью
"DDR4 3200MHz" vs "DDR5 3200MHz" — векторно почти идентичны, но абсолютно несовместимы

LLM можно использовать для трансформации запроса пользователя (вычленения важной информации), потом делать полнотекстовый как сейчас.
Результаты можно ранжировать тоже с помощью LLM. Но сам поиск — скорее нет чем да.