Здравствуйте, Артём, Вы писали:
Аё>Применительно к собственно ручному поиску юзером, и к поиску агентом (llm). Если агент (скажем, модель крутится в ollama) — нужно ему указать (mcp) Tool или возможны какие-то низкоуровневые интерфейсы для RAG?
Вставлю 5 коп, хоть и вопрос не ко мне. Глянь https://github.com/mraza007/echovault
Мне кажется это примерно то что ты спрашиваешь.
Вопрос к nuzhny — скажем, есть таблица parts (например, бп, видеокарты, материнки и т.п.) у каждой позиции есть короткое поле description. карта/бп/материнка подбирается к недособранному компу (это контекст) и должно абсолютно 100% подходить. Процесс "подходит/неподходит" на данный момент прошит программно. Есть поиск по подстроке description, программно, реализован 100500 лет назад.
Вопрос 1 — если в пре-процессить поле description в вектор и доложить рядом файлик sqlite-vector, а потом при поиске по description, искать вектор nearest neighbor вместо подстроки- это имеет право на жизнь? Или полный бред?
Вопрос 2 — если добавить в вектор также как-то информацию об к какому набору/платформе подходит эта деталь, а потом опционально при поиске по description добавлять какие-то флаги о "ищи внутри набора Х"- чтобы искало "в общем" и опционально "сузить до подходящих к Х" это имеет право на жизнь?
Применительно к собственно ручному поиску юзером, и к поиску агентом (llm). Если агент (скажем, модель крутится в ollama) — нужно ему указать (mcp) Tool или возможны какие-то низкоуровневые интерфейсы для RAG?
Re[2]: Семантический поиск / Vector Index в каталоге
Здравствуйте, pva, Вы писали:
Аё>>Применительно к собственно ручному поиску юзером, и к поиску агентом (llm). Если агент (скажем, модель крутится в ollama) — нужно ему указать (mcp) Tool или возможны какие-то низкоуровневые интерфейсы для RAG? pva>Вставлю 5 коп, хоть и вопрос не ко мне. Глянь https://github.com/mraza007/echovault pva>Мне кажется это примерно то что ты спрашиваешь.
Я прочитал новость про какого-то чела из гугла репку про память для llm (что-то про авто-индексирование каталога), оттуда увидел, что он использовал sqlite-vec, ещё раз проверил что это не первоапрельская шутка .
Я спрашиваю про другой юзкейс, а именно- дополнить или заменить олдскульный индекс по префиксу/суффиксу description на векторный индекс, чтобы если юзер произвольно сформулировал описание- оно всё равно по смыслу нашло.
Здравствуйте, Артём, Вы писали:
Аё>Вопрос 1 — если в пре-процессить поле description в вектор и доложить рядом файлик sqlite-vector, а потом при поиске по description, искать вектор nearest neighbor вместо подстроки- это имеет право на жизнь? Или полный бред?
Я делал чтото навроде. Штука в том, что описание и то, что пользователь может понавводить, могут основательно отличаться. Поэтому нужно и то и другое приводить к какому то каноническому виду, тогда работать будет гораздо лучше. Но вот сама эта канонизация это задачка для llm.
Самое сложное это ввод пользователя, который может ввести amd intel nvidia radeon meteor halo laptop desktop и использовать разные языки для этого.
Здравствуйте, Артём, Вы писали:
Аё>Вопрос к 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. Но сам поиск — скорее нет чем да.
Здравствуйте, Артём, Вы писали:
Аё>Я спрашиваю про другой юзкейс, а именно- дополнить или заменить олдскульный индекс по префиксу/суффиксу description на векторный индекс, чтобы если юзер произвольно сформулировал описание- оно всё равно по смыслу нашло.
Это не другой кейс, а часть того что я предложил. Если вкратце, то выше реализовано примерно следующее: заданные наборы данных токенизируются моделью и складываются в БД (угу, sqlite) а дальше запросы пользователя точно так же токенизируются и делается FTS, если его выхлопа не хватает, то сваливается в фолбек семантический (вероятно, просто косинусное подобие) + взвешивание. Смысл не просто в векторном подобии, а в токенизированном подобии, что должно улучшать поиск по синонимичным понятиям.
Если б не ленился, то глянул бы echovault\src\memory\search.py — там всего 100 строк. Остальное — просто обвязка для MCP/Tool.
.
