Ну вот пока у меня это самое частое применение на практике. Самое неинтересное по сути, как грубый фильтр для объёмов.
embeddingGemma использую, и мне пока с ней не всё понятно. С модельками от OpenAI попроще было.
В смысле - по наличию ключа? Я не знаю, как можно задавать эти признаки другого типа. Во времена word2vec было такое интересное развлечение - сопоставлять сущности по каким-то критериям. Скажем, кто более "рыжий" - "сосна" или "космический корабль".
Вот тут, к слову, большой простор для работы с эмбеддингами: чистая техничка, не семантика. Взять здоровенный сайт и выловить дубли по смыслу, или странички, почему-то выпадающие из подразумеваемого кластера - с этим вложения справляются наотличненько. Скажем, там просто рерайт человеку пару раз продали, а тут - текст вылетел, или какой-то левый блок подгрузился из-за системного бага. На днях такое было: Битрикс текст с категории начал лепить на подкатегории допником после обновления шаблона. Как бы я это увидел при обычном сканировании? А вложения запросто вычислили.
Запрос-то в таком виде непонятен. Для LLM - тоже. Я, к примеру, так и не понял, что может искать по этому запросу кто-то - я не в теме.
Это поисковик имеет статистику какую-то (если запрос не уник) - кто спрашивает, чего ищет, чего хочет скорее всего. А у языковых моделей таких данных нету, если там 2-3 ключа всего, и нет выраженного "купить прям щас" или там "это чё".
Как по мне - интереснее взять пользовательский сегмент, запрос по его интентам препарировать, и уже по подзапросам (на естественном языке) проводить дальнейший анализ.
Вот и получается: тут отвечено на 8 из 10 подзапросов, тут - всего на 3, да и то криво.
А если брать ключи - то всё же на уровне вхождений считать достаточно, дальше погружаться смысла не вижу.
Для текстового анализа входные данные стоит фильтровать. Я, к примеру, заведомо откидываю перекормленные хосты, отличающиеся структурно страницы и всё такое. Там только шум.
Для моделей эмбеддингов контекста не хватает. Тут хоть бертообразных брать, хоть серьёзные LLM. Для них всё одно - что "дохлая кошка", что "кавайный котёночек". В семантическом-то многомерном пространстве они вплотную.
Рамиль, ну есть же уже тесты такого рода в паблике на объёмах. Суть теста примерно та же. А в выводах - наличие всех слов по кластеру на страничке.
То, что в топах в принципе нерелевантного добра выше крыши (особенно у Яндекс) - дело привычное изначально. Тут партнёр самого Яндекс, там - хостовый бонус или бонус новичка, тут дату обновили, там исторические данные Яше говорят, что хороший URL.
Текстовая релевантность - это много, но далеко не всё. Чем дальше, тем больше решает статус хоста, а не качество контента.
Примерно как по ТВ на ток-шоу: людей учат жить какие-то актеришки или статусные проститутки вместо учёных, психологов, врачей.
Контекста-то нету, только ключевые слова. Семантический поиск без контекста - не полезнее bm25, как по мне.
Тема интересная. Но вот условия проведения теста вызывают большие вопросы.
Как можно поисковый запрос (список ключевиков) сопоставлять на векторах с целым контентным блоком (пусть и порезанным на шинглы)? Тогда уж формулируем полноценный запрос на естественном языке и ищем максимально соответствующие ему шинглы.
Второй момент - это анализ топов. Там сайты-то не по семантической релевантности выводятся, а по комплексным метрикам (хостовые, исторические и т.п.). Если брать именно текстовый контент, то чаще всего там нужного-то и нету.
Я локально использую. На HuggingFace свободно лежит в нескольких версиях. Можно слить, запускать локально через ту же LLMStudio. Я к "лягушке" прикрутил, теперь при сканировании можно сразу в модельку отправлять и получать результаты анализа.
Но вот результаты, мягко говоря, противоречивые получаются. Грубые задачки решает. А если взять как базу для семантического поиска по сайту в самой "лягушке" - выходит дичь.
Моделька маленькая, 300 мб всего, на не самой сильной машине без тормозов бегает. Гугл её под смартфоны точил изначально. Многоязычная.