UEmbed мультимодальная модель эмбеддингов от Alibaba 2B, 4B, 9B UEmbed это decoder‑only модель, которая в одном проходе генерирует сразу два типа представлений: - плотные (dense) для семантического поиска и задач типа retrieval - разреженные (sparse, лексические) хорошо работает для классического лексического поиска При этом модель принимает на вход текст, изображения и видео и выдаёт для них совместимые эмбеддинги, то есть можно искать текст по картинке, картинку по видеофрагменту и т. п. Единое векторное пространство: разные модальности приводятся к общему представлению, что удобно для гибридного поиска. Гитхаб HF #multimodal

Google готовит единый интерфейс для голосового поиска на Android Разработчики Google тестируют обновление виджета поиска для Android. В бета-версии приложения привычный значок микрофона больше не просто записывает голос для текстового запроса, а открывает полноценное меню с несколькими режимами работы. На нижней панели появились переключатели между стандартным поиском, ИИ-режимом, интерактивным помощником Search Live и распознаванием музыки Song Search. Интерфейс получил горизонтальную панель инструментов по аналогии с Google Lens, а само приложение запоминает последний выбранный режим и запускает его по умолчанию при следующем клике. В ИИ-режиме добавили возможность приостановить запись и отредактировать транскрибированный текст перед отправкой.

Отделяем текстовый скоринг от продуктового ранжирования Как оказалось, научить поисковый движок находить релевантные документы = только половина задачи. Следующий вопрос в том, какие из найденных совпадений важнее для конкретного продукта. Окей, движок уже умеeт строить индексы по нескольким полям (title, abstract и т.д.) и поддерживает разные типы поиска: например term, phrase, prefix, фразовый поиск. Но после поиска вклад каждого совпадения просто добавлялся в итоговый вес документа. Например, для запроса`title:diabetes abstract:"type 1" abstract:insulin*` мы находили три независимых совпадения: • term - diabetes в title; • phrase - "type 1" в abstract; • prefix - insulin* в abstract. Для каждого совпадения BM25 считал свой вес, после чего все веса просто суммировались: BM25 total doc score = BM25(title:diabetes) + BM25(abstract:"type 1") + BM25(abstract:insulin*) Базово текстовая релевантность оценена за счет частоты термина, его редкости среди всех документов, длине поля. И это ок, но продуктово мы помимо всего знаем, что совпадения в заголовке обычно важнее совпадения в abstract, и что точная фраза часто ценнее совпадения по одному слову (или хотя бы по префиксу). Поэтому я подсмотрела идею с Rank Profiles - добавлением правил ранжирования по заданым критериям, который добавляет веса нужным докам без переиндексации. Пример профиля из конфига: rank_profile: name: debug-weights field_weights: title: 1.5 query_type_weights: term: 1.5 phrase: 1.7 prefix: 0.5 Теперь BM25 по-прежнему считает базовый score каждого совпадения, но перед суммированием вклад умножается на коэффициент: document score = BM25(title:diabetes) × 1.5 × 1.5 + BM25(abstract:"type 1") × 1.0 × 1.7 + BM25(abstract:insulin*) × 1.0 × 0.5 Поскольку индекс уже хранит информацию о каждом найденном совпадении (поле, тип запроса и базовый вес), политику ранжирования теперь можно менять прямо во время поиска - без переиндексации документов с явным разделением ответственности: • основная retrieval часть находит совпадения и сохраняет их контекст; • BM25 считает базовую текстовую релевантность; • Rank Profile задает правила, по которым совпадения влияют на итоговый вес документа; • Explain разбивка помогает понять, почему документ получил именно такой вес. Чтобы было проще отлаживать ранжирование, добавила Explain-панель. Для каждого документа можно посмотреть, из каких вкладов сложился итоговый вес: какое совпадение сработало, в каком поле, какой базовый вес посчитал BM25, какие коэффициенты применились и какой вклад каждое совпадение внесло в итоговый результат. На скрине из TUI (который, кстати, был тщательно причесан и допичкан инфо панельками) как раз видно такую разбивку по весам для каждого найденного документа. Сейчас Rank Profile умеет учитывать поле документа и тип совпадения. В дальнейшем список сигналов можно расширить: например, добавить свежесть документа, популярность или поведенческие сигналы (клики пользователей). Главное, чтобы поисковый движок умел вычислить такой сигнал - тогда его можно включить в ranking pipeline без изменения индекса. В итоге базовый текстовый скоринг остается отдельным слоем, а продуктовая логика ранжирования начинает жить поверх него. Это позволяет менять стратегию ранжирования, не меняя сам индекс.

🌍 Как правильно промптить LLM для планирования путешествий: что говорит наука Пока путешествую по Мадагаскару, задался вопросом: а как вообще правильно просить LLM спланировать поездку и составить маршрут? TL;DR: пишите как удобно, вставляйте местные названия, прямо просите искать на языке страны и требуйте ссылки на источники — особенно для дат, цен и расписаний ✈️ 1️⃣ Язык промпта — гибрид Инструкции модель лучше выполняет на английском, но факты о стране точнее «вспоминает» на её языке — перевод смывает культурный контекст (в бенчмарке CulturALL нативные промпты дали +8% точности). Промптинг на языке культуры также снижает галлюцинации о ней. 👉 Рецепт: запрос — на удобном языке, а топонимы, районы и блюда — на языке страны. 2️⃣ Явно просите искать на местном языке У LLM есть скрытый bias: на каком языке спросили — на таком и ищет, а без локальных источников тянется к высокоресурсным языкам (Faux Polyglot). Запрос на английском = «туристический интернет», а не то, куда ходят местные. 👉 Пишите прямо: «ищи и на малагасийском, и на французском, и на английском, для ресторанов и транспорта приоритет — локальные сайты». 3️⃣ Зависит ли от страны? Да, и тут парадокс 🤯 ▫️ Франция/Япония: многое дублируется на английском, локальный поиск даёт бонус в «длинном хвосте» — события, нетуристические места. ▫️ Низкоресурсные языки (тот же малагасийский): самое ценное есть только локально, но модель хуже понимает язык. Оптимум — двуязычный поиск + синтез (paper). ▫️ Важна ещё и «оцифрованность» страны: про регионы с бедным интернетом модель знает мало на любом языке. ⚠️ Нюансы, о которых забывают: 🔸 Когда источники на одном языке, а ответ на другом, модель хуже рассуждает и путает язык ответа (бенчмарк XRAG, EMNLP 2025). Фиксируйте: «отвечай по-русски, укажи источник каждого факта». 🔸 Разные модели ≠ одинаковое поведение: одной лучше английский, другой — нативный язык. Универсального правила нет. 🔸 Неанглийский текст «дороже» по токенам — чисто инженерный аргумент 💸 🔸 Цены, визы, расписания — только через поиск, по памяти модель уверенно выдаст устаревшее. 📊 Оценка завышена (XBCP и X-WebAgentBench) для travel-planning нет хорошего ground truth так как текущие исследования агентных систем в основном англо-центричны. @mashkka_ds За вдохновение спасибо @travel4_you & @runoutofthetown #llm #Claude #agent

USRW 2026: Call for Papers — дедлайн продлён до 27 июля 🔎 Это тот самый Unified Search and Recommendation Workshop, который я недавно упоминал в посте про мои воркшопы на RecSys. Теперь можно наконец рассказать подробнее: мы опубликовали программу и открыли приём статей. Для меня это первый опыт организации отдельного воркшопа — и особенно приятно, что он посвящён теме, вокруг которой, собственно, и строится этот канал. Главная идея USRW проста: поиск и рекомендации слишком долго развивались как разные дисциплины, хотя обе решают одну и ту же задачу — помогают человеку найти нужный контент. С появлением LLM, generative retrieval и агентных систем граница между query-driven search и feed-driven recommendation становится всё менее естественной. Но «объединить» не значит просто объявить поиск и рекомендации одной и той же задачей. Мы хотим разобраться, что действительно можно сделать общим — данные, представления, генерацию кандидатов, ранжирование, интерфейсы и протоколы оценки, — а где различия в сигналах, UX, задержке, стоимости и управляемости остаются принципиальными. В программе: 🎤 Mounia Lalmas (Senior Director of Research, Spotify) — «Building AI-Driven Experiences at Scale: When Search and Recommendation Become One Conversation» 🎤 Harrie Oosterhuis (Associate Professor, University of Amsterdam / Amazon Scholar Amazon Music) — «Learning to Rank Everything, Everywhere and All at Once» 🧭 Dive Deep tutorial, который мы проведём вместе с Gustavo Penha. Поговорим об общих корнях поиска и рекомендаций, слоях их возможного объединения, semantic IDs, generative retrieval, языковых интерфейсах, агентах и реальных production-компромиссах. В Call for Papers ждём работы про: • единые модели поиска и рекомендаций; • общие представления пользователей и объектов; • моделирование поведения между search- и feed-сценариями; • LLM для понимания запросов и намерений; • generative retrieval, semantic IDs, RAG и agentic discovery; • смешанные поисково-рекомендательные интерфейсы; • общую инфраструктуру и методы оценки; • эффективность, устойчивость и безопасность; • индустриальные кейсы, датасеты и benchmarks. Формат: 4–9 страниц без списка литературы, ACM SIGCONF, двойное слепое рецензирование. Воркшоп неархивный: принятая статья будет размещена на сайте USRW, но авторы сохраняют право впоследствии отправить её расширенную версию в конференцию или журнал. Также выберем лучшую работу для Best Paper Award. ⏰ Дедлайн подачи: 27 июля 2026 года, 23:59 AoE 📍 Воркшоп: 2 октября 2026 года, Миннеаполис, ACM RecSys 2026 🔗 Сайт, полный CFP и подача статьи: https://usrw-workshop.github.io/2026/ Организуем USRW вместе с Sean MacAvaney (University of Glasgow), Gustavo Penha (Spotify), Léa Briand (Deezer) и Clémence Vast (Deezer). Если у вас есть работа на стыке поиска и рекомендаций — от новой модели до индустриального кейса или benchmark, — буду очень рад увидеть её на USRW. И буду благодарен, если перешлёте этот анонс коллегам, которым тема может быть близка 🙌

😍 AI SEO / GEO принципы дают результат Алгоритмы и принципы зашитые в систему (и это всё ИИ), На выходных ещё попался очень интересный эксперимент с loop engineering применительно к SEO (🎞 видео), где ты ставишь ИИ агенту цель → он ищет точки роста как вырасти в SEО → сам анализирует результаты в Google, Яндекс → сам пишет стратегию поднятия в топ. В общем крутая идея. Также (о чем я знал, но забыл применить) - - LLM.txt на домен и LLM.txt на статью в Markdown. ChatGPT, Claude, Perplexity и др. нейронки поощряют домены из которых можно БЫСТРО извлечь контент. Поэтому ГЛУПО закрывать страницы от краулеров/парсеров, ибо этим парсером может быть chatGPT, который мог бы выдвать вашему потенциальному клиенту ссылку на ваш сайт. Плюс в 2026 рулит авторство (тот самый EEAT), поисковики не брендовый контент контент который не имеет личного бренда или бренда компании

Сегодня увидел OpenSERP: опенсорсный инструмент, который отдаёт поисковую выдачу из Google, Yandex, Baidu, Bing, DuckDuckGo в виде JSON. По работе постоянно проверяю поисковую выдачу под SEO, как ранжируется, что в топе и всё это в разных поисковиках и регионах. Тут, всю эту работу можно делать с агентом и получать структурированный ответ: заголовки, ссылки, сниппеты, позиции и SERP-фичи (AI-ответы, блок с ответом, похожие запросы), и сразу из нескольких поисковиков. Фишка тут в том, что API ключи от самих поисковиков не нужны. OpenSERP парсит их живую выдачу напрямую, но может прилететь капча, поэтому в конфиге поддерживаются прокси HTTP/SOCKS5. Обращаться можно через его API или CLI:

/{engine}/search — веб-поиск по конкретному поисковику /{engine}/image — поиск картинок /mega/search — поиск по нескольким движкам /extract — извлечение чистого контента с одной страницы

Выдача фильтруется по языку, региону, датам и тд. Если поднять у себя, то работаешь бесплатно. Можете скормить своему агенту доки или гитхаб чтобы подключить. @tips_ai #tools