Поисковые технологии *

В этой статье разберу JSON-LD для сайтов на Tilda: что именно размечать, как разделять общий код и код конкретной страницы, где проверять микроразметку и какие ошибки чаще всего появляются после правок сайта.

Материал не про то, как скопировать готовый JSON из генератора. Такой вариант годится только для самых простых страниц.

На коммерческом сайте разметку лучше собирать от структуры: есть сайт, организация, конкретные страницы, услуги, статьи, контакты, изображения, хлебные крошки и вопросы.

Часть этих данных относится ко всему сайту, часть - только к одной странице.

Если это не разделить сразу, дальше начинаются дубли, старые URL, одинаковые схемы на всех страницах и странные предупреждения в валидаторах.

Для примеров возьму нейтральную нишу - учебный центр.

write‑tools, безопасность, метаданные

Это вторая часть статьи по Sping AI в Джеймикс. Короткая аннотация первой — на случай, если прошло время или вы её не читали: мы собрали read‑only агент внутри Джеймикс‑приложения. Пользователь задаёт вопрос на естественном языке; ChatClient из Spring AI крутит agent loop — дёргает @Tool‑методы, пока не наберёт достаточно данных для ответа. Каждый tool данные читает через DataManager с явным fetch plan‑ом, поэтому почти полностью остаётся внутри рамок системы безопасности Джеймикс и возвращает только нужные модели поля. UI — обычный Джеймикс‑вью, без REST‑прослойки. Также, в первой части мы убедились, что выбор модели — не деталь: модель без надёжного native tool calling ломает всю схему. Если первую часть не читали — начните с неё, код ниже строится как продолжение.

В этой части мы дадим агенту право менять данные. И вот здесь, в отличие от первой половины, начинают всплывать вопросы, которые ни Spring AI, ни большинство туториалов по агентам обычно не поднимают: под каким пользователем выполняется tool, что делать с транзакциями, как аудировать действия, инициированные моделью, и как заставить агента работать с вашей доменной моделью без ручного перечисления сущностей в промпте.

Это не косметические изменения, а ровно те решения, что отделяют демо от приложения, которое можно показывать заказчику.

Полный исходник всего, что мы здесь обсуждаем, лежит здесь: https://github.com/jmix‑edu/ai‑warehouse — можно клонировать и сразу запустить.

Что добавляем

Deep Research часто описывают как «LLM с интернет-поиском». Однако если система просто делает несколько поисковых запросов, читает часть выдачи и пишет ответ, то она упускает несколько важных аспектов, без которых невозможно полноценное исследование.

В настоящем глубоком исследовании, помимо доступа к актуальным источникам, важен и сам исследовательский процесс: понять исходный вопрос, не потерять ограничения, разложить задачу на проверяемые части, собрать доказательную базу, отличить найденные факты от выводов модели, зафиксировать пробелы и собрать итоговый отчёт.

В этой статье мы расскажем о том, как решили задачу построения системы B2C Deep Research на основе Instruct-модели (GigaChat Ultra 3.1), в которой модель выполняет специфицированные задачи, а логика исследования реализована с помощью конвейера из набора ролей, условий завершения, циклов поиска и постепенного накопления контекста, подкреплённого цитатами. Так Deep Research становится не просто набором промптов с доступом к источникам в интернете, а управляемым исследовательским контуром.

Нейросети уже отправляют на сайты теплый трафик. На реальном запросе и на цифрах нашего проекта показываю, от чего зависит попадание в их ответы и что мы для этого делаем.

Это первая из двух статей про построение AI-агента внутри Джеймикс-приложения. Джеймикс (или Jmix, ex. CUBA) - высокоуровневый фреймворк для разработки корпоративных приложений на Java, автор не будет слишком сильно в него погружаться, в наше время любой запрос к AI даст Вам всю нужную информацию. В этой части мы соберем минимальный, но рабочий пример: пользователь задает вопрос на естественном языке, агент решает, какие операции вызвать на бэкенде, дергает их и возвращает осмысленный ответ. В качестве предметной области возьмем склад - сценарий, узнаваемый для большинства бизнес-приложений и достаточно широкий, чтобы во второй части обсудить уже не только чтение, но и запись данных, безопасность, fetch plans и метаданные.

Зачем это вообще нужно? Данные корпоративного приложения живут за списками и формами с фильтрами. Это отлично работает, когда пользователь знает, по каким полям фильтровать - и плохо для размытых, многокритериальных вопросов вроде "где у нас заканчивается кофе тёмной обжарки по северным складам?". Когда иначе пришлось бы открыть несколько экранов и руками свести результаты, AI-агент даёт возможность просто спросить - и собирает ответ из бэкенд-операций, которые у вас уже есть.

Почему строить это внутри Джеймикс-приложения, а не отдельным сервисом? В случае Джеймикса агент едет на том же доступе к данным и той же безопасности, что уже есть во фреймворке, его tools идут через DataManager, поэтому он видит ровно то, что разрешено текущему пользователю - никакого параллельного пути к данным, никакого обхода прав. Именно это свойство делает агента приемлемым в enterprise-контексте, и это поведение - сквозная нить обеих частей.

Два сайта, одна тема, оба с правильными Title, H1 и ключами. Один в топ-3, другой на второй странице. Какого… В смысле, почему?

Ну понятно, у первого больше ссылок или лучше поведенческие. Так-то это действительно так, но это не полный ответ. Полный объясняет, почему нельзя просто добавить ключей в текст и ждать результата.

Разберемся, что происходит между вводом запроса и появлением страницы в выдаче.

Когда нейросеть отвечает на вопрос и показывает блок «источников», кажется, что у всех систем это одно и то же — список ссылок, на которые модель опиралась. На деле за этим блоком в каждой системе стоит своя реализация: свой способ обмена с сервером, свой формат ответа, свои поля, из которых интерфейс достаёт цитаты. Мы разобрали сетевой обмен веб-клиентов трёх систем — ChatGPT, Gemini и DeepSeek — и параллельно прогнали через них один и тот же набор запросов по 10 раз, чтобы понять не только техническое устройство цитирования, но и что эти системы реально цитируют.

Сразу оговорка: я основатель RankCaster AI — платформы, которая управляет видимостью брендов в ответах нейросетей. То есть мы изучаем категорию, в которой сами работаем. Чтобы не подыгрывать себе, мы исключили собственный домен из всех таблиц ещё до подсчётов, а ограничения методики описали в полном тексте исследования. Здесь — техническая часть: разбор механики цитирования.

В наши дни поиск информации стал почти скучен и почти тривиален. На 90% запросов и вовсе можно получить ответ от встроенной в поисковик нейросети, без необходимости прокликивать пару десятков ссылок. Разумеется, так было не всегда. Автору статьи, например, до сих пор непривычно пользоваться нейроподсказками. Прочитать текст по ссылке своими глазами  —  бесценно, если требуется на 100% точная информация.

Поколение 35+ наверняка помнит, как интернет выглядел без Google и Яндекса. Кто-то был завсегдатаем школьной или районной библиотеки. Кому-то приходилось каталогизировать и размечать конспекты учебных лекций вручную. Казалось бы, это не слишком связанные вещи — где интернет-поиск и где допотопная картотека. Но без второго не было бы первого.

В сегодняшней статье мы решили посмотреть, как люди учились индексировать, хранить, а самое главное, быстро находить информацию в доцифровую эпоху. Вместе мы пройдем весь путь от седой древности до вездесущего chatGPT. Присаживайтесь поудобнее, первая остановка  —  Месопотамия.

Привет, я Вит Глинка, backend программист в компании Deeplace, в которой среди прочего активно работают в области winetech. Хочу презентовать нашу последнюю фичу в этой области — raFTI.v5.3 — систему полнотекстового поиска.

Всем привет! Меня зовут Вардан Манучарян, я аналитик в команде Монетизации Авито, и мы отвечаем за механику алгоритмов продвижения, то есть управляем порядком, в котором пользователи видят объявления. Для этого нам нужно отслеживать, как изменения в ранжировании влияют на бизнес и покупателей. В этой статье расскажу про интерливинг, — метод, который помогает корректно проводить A/B-тесты с изменением ранжирования. Статья будет интересна аналитикам, которые проводят много A/B-тестов.

В наших проектах локальное SEO часто появляется как побочный эффект роста: компания расширяет зону доставки, открывает филиал, начинает выезжать за пределы города, получает заявки из соседних районов и в какой-то момент понимает, что сайт плохо объясняет географию работы.

Дальше почти всегда возникает соблазн быстро закрыть спрос страницами под города и районы. Технически это легко. Особенно на конструкторе: копия страницы, новый заголовок, другой топоним, пара правок в тексте, публикация.

На короткой дистанции такой подход выглядит продуктивно: страниц стало больше, семантика закрыта, в отчёте есть движение.

Проблема в том, что поисковая система и пользователь смотрят на страницу не как на строку в плане работ. Им важно другое: есть ли на этой странице самостоятельная ценность. Объясняет ли она условия работы в конкретной зоне. Помогает ли принять решение. Снимает ли вопросы по срокам, доставке, выезду, цене, адресу, маршруту, ограничениям.

Трансформация поисковой парадигмы: От классического SEO к эпохе GEO

Привет, меня зовут Владимир Назаров, я руководитель агентства поискового маркетинга Head Promo, практикующий эксперт по SEO и GEO продвижению.

В 2025 году мы одни из первых в России выпустили гайд-инструкцию на основе нашего эксперимента по попаданию бренда в ответы нейросетей, суммарно его посмотрело более 30 000 человек. Прошло уже 9 месяцев с выхода прошлой публикации, пришло время обновить гайд и дополнить его практическими кейсами уже 2026 года.

Во многих поисковых сценариях пользователь начинает не с пустой строки запроса, а с существующего результата.

Пользователь открывает статью и хочет найти похожие материалы. Покупатель просматривает карточку товара и ищет близкие варианты. Инженер поддержки разбирает инцидент и хочет увидеть прошлые случаи с теми же симптомами. Во всех этих ситуациях у пользователя уже есть релевантный документ для начала поиска.

Этот сценарий традиционно называют More Like This (MLT): функцией поиска документов, похожих на выбранный. В статье под MLT понимается поиск от уже известного документа, а не от заново введённого запроса.

Классический подход MLT (поиск похожих документов) основывался на сравнении текстовых совпадений. Современные реализации всё чаще используют эмбеддинги: числовые представления документов. Поисковый индекс хранит эмбеддинги в виде векторов, а поисковая система может находить документы с близкими векторными представлениями.

Современные поисковые системы уже не просто сопоставляют ключевые слова. Когда вы ищете «уютный детектив, действие которого происходит в Париже», а получаете результаты вроде «атмосферный детективный роман во Франции», это векторный поиск в действии: документы и запросы превращаются в списки чисел — эмбеддинги, — а поисковый движок находит документы, чьи векторы ближе всего к вектору запроса.

Manticore Search поддерживает это из коробки. Внутри используется структура данных HNSW: граф, который соединяет близкие векторы и позволяет быстро находить ближайших соседей без сканирования каждого документа. Благодаря этому векторный поиск по миллионам документов выполняется за миллисекунды.

Всем привет! Меня зовут Петя Портнов, я работаю в Ozon ведущим разработчиком в команде среднего поиска — слоя, который ранжирует поисковую выдачу.

Представьте, что вы вводите запрос в поисковую строку маркетплейса. За этим простым действием скрывается сложный поисковый пайплайн: миллионы товаров фильтруются, ранжируются и сортируются по релевантности. Но как именно система решает, что показать первым? В основе этого решения лежат вычисления, среди которых — сотни разнообразных формул, учитывающих цену, рейтинг, популярность, персонализацию и другие факторы. По мере развития системы таких формул становится всё больше, а сами они усложняются. В какой-то момент вычисления превращаются в узкое место: начинают потреблять значительную долю CPU, создают множество промежуточных объектов — и так для каждого поискового запроса. Возникает вопрос: как снизить стоимость таких вычислений в JVM?

В этой статье я расскажу, что сделали мы, чтобы снизить нагрузку на систему: как заменили интерпретирующий движок формул на динамический компилятор, выполняющий построение эффективного байт-кода, отлично векторизующегося JIT-компилятором. Это текстовая версия доклада с Joker 2025 с дополнениями, которые не вошли в выступление или появились в проекте уже после конференции.

Рост позиций сайта в традиционной поисковой выдаче больше не гарантирует переходы пользователей на сайт. Генеративная выдача (модули AI Overviews в Google и ЯндексНейро) перехватывает трафик на нулевом экране. Искусственный интеллект выдает готовый текст и точные ответы на вопросы пользователя раньше, чем тот доберется до ссылок на сайты. Одновременно с этим поисковые алгоритмы перестали ранжировать контент, который представляет собой банальный рерайт и не несет новой информации.

В этой статье разбор внутреннего механизма работы современных поисковых систем, механики Query fan-out и проблемы коллапса языковых моделей. Представлена прикладная методология, которая помогает проверить оптимизацию страниц, проанализировать Share of Voice (доля ответов) бренда и настроить точный учет переходов в условиях разрыва UTM-меток.

AI-агенты умеют искать по Obsidian-хранилищу, но делают это слишком топорно через glob и grep. Да, для кода эти инструменты работают потрясающе, но хранилище в Obsidian не имеет такой же высокой структурированности. Искать по нему чисто лексически – значит терять инсайты, которые связаны по смыслу.

Чтобы решить эту проблему, я разработал Obsidian Hybrid Search – MCP-сервер и CLI, которые дают агенту мощный поисковый движок поверх заметок.

GitHub + Obsidian Plugin

Когда говорят про RAG, его часто описывают как простой способ улучшить LLM‑систему: добавить поиск по внешним данным, найти релевантный контекст, передать его модели и получить более точный ответ.

На уровне идеи это действительно выглядит логично.

Но в реальной системе RAG — это не только способ обогатить ответ. Это отдельный операционный слой, который влияет на задержку, размер prompt, количество input tokens, стоимость запроса, качество ответа, SLA и требования к наблюдаемости системы.

Я хотел посмотреть на это не в формате общих рассуждений, а на небольшом локальном стенде: где именно появляется дополнительная нагрузка, какие параметры сильнее всего влияют на latency, почему больше контекста не всегда означает лучшее качество и почему стратегия retrieval должна зависеть от типа вопроса и структуры данных.

Это не промышленный benchmark и не попытка получить универсальные цифры. Скорее серия контролируемых экспериментов: посмотреть на механику RAG pipeline и компромиссы, которые часто остаются за кадром, когда RAG описывают просто как «поиск + LLM».

Вы начинаете набирать запрос в поисковой строке на Ozon и сразу видите список вариантов. Иногда кажется, что поиск читает мысли. Хотя магии здесь нет. Есть система подсказок или саджестов (от англ. suggest), которая должна за доли секунды понять, что вы хотите, и предложить лучший вариант. На всё — 300 мс. Если она думает дольше, пользователь замечает «подвисание», раздражается и вводит запрос вручную.

Рано или поздно возникает вопрос, как одновременно держать высокое качество и жёсткие ограничения по скорости? Долгое время мы решали это классически. Брали готовые запросы и обучали градиентный бустинг над деревьями решений выбирать лучшие варианты. Работает? Да. Хватает ли этого? Уже нет. В какой-то момент мы упёрлись в потолок качества. Улучшать ранжирование становилось всё сложнее, а эффект был всё меньше. Тогда мы попробовали другой подход и начали генерировать подсказки, а не выбирать из готовых.

В 2023 году мы рассказывали, как в Поиске по архивам появилось распознавание рукописных документов и почему сама по себе расшифровка архивного текста — нетривиальная задача. Старые почерки, сложная вёрстка, нестандартные формулировки и огромное разнообразие источников делают архивы трудным доменом даже для сильных OCR‑моделей. 

По мере развития сервиса стало ясно, что одной только расшифровки недостаточно: чтобы действительно помогать пользователям находить своих родственников, нужно не просто видеть слова на скане, а понимать, кто именно упомянут в записи, в какой роли и как связан с другими людьми.

Теперь в Поиске по архивам работает новая модель распознавания документов. Она не только распознаёт текст архивного файла, но и структурирует информацию из него. Например, понимает роли и связи между разными людьми: «родившийся», «отец» и «мать» для рождения или «жених», «невеста», «свидетель» для брака. 

Меня зовут Даша Виноградова, я руковожу универсальными применениями компьютерного зрения в Яндексе. Вместе с Аней Сидоровой, главным разработчиком распознавания архивов, мы расскажем, как мы сделали шаг от распознавания текста к извлечению структуры и смысла из архивных документов: как мы перестраивали OCR‑пайплайн, почему нам не подошли универсальные VLM‑модели и как пытались разобраться, кто есть кто: отец, мать, жених или свидетель.