Рынок потихоньку обретает опору вновь.
Semrush выкатывает одни из первых внятных исследований про механику AI-ответов: какая логика отбора, какие используются источники и критерии контента.
Сегодня много статистики с моими комментариями)
Один из наших пользователей недавно пришёл к нам со знакомой проблемой: поиск внезапно стал заметно медленнее, хотя внешне ничего явно не ломалось.
Сервис работал, ошибок в логах не было, загрузка CPU выглядела нормально, но пользователи уже начали жаловаться, что поиск тормозит.
Так обычно и проявляются проблемы с поиском в продакшене. Не как драматичный сбой, а как медленное, ползучее ухудшение. Чуть больше трафика здесь, чуть больше индексации там, и прежде чем вы это заметите, производительность уже просела.
К тому моменту, когда пользователи это замечают, настоящая проблема нередко копится уже несколько часов. Без хорошей видимости остаётся только гадать: система перегружена? Одна таблица съедает ресурсы? Или незаметно что-то идёт не так?
Вот почему мониторинг важен. С ним расплывчатое «поиск стал медленным» превращается в проблему, которую можно диагностировать и исправить.
К тридцатилетию публикации проекта 1994 года, который остаётся самым скорострельным морфологическим анализатором.
Давным-давно, когда Рунет только появлялся, морфологические анализаторы и системы контроля орфографии уже производили вау-эффект: они не только сводили разные словоформы к основной (словарной), но и зачастую умели их склонять/спрягать, описывали грамматику вхождений и предлагали варианты замены ошибочных начертаний. Да и чуть позже, при появлении первого русского морфологического поиска в Интернет – это был Апорт! – на выставках тоже равнодушных не было. Тогда и родился libmorph.
Самый неприятный тип инцидента — когда база данных не падает полностью, а просто начинает работать медленнее.
Пользователи замечают это сразу. Жалобы начинают поступать. Технически всё по-прежнему работает, но явно что‑то не так.
И обычно самое сложное здесь не заметить проблему, а понять, что на самом деле происходит.
Начиная с Manticore Search 24.4.0, компактизация RT-таблиц использует более эффективную модель выполнения. Вместо последовательного слияния пар чанков оптимизация теперь поддерживает два важных улучшения:
Из этого материала вы узнаете о том, как работают векторные базы данных, разобравшись с широким диапазоном тем — от основ поиска по сходству, до стратегий индексирования, которые позволяют применять на практике крупномасштабный поиск данных.
Огромное число авторов используют хэштеги для пометки своих постов. А также для заголовков, вносят эту информацию на картинки, в инфографику для видео и всячески применяют для поиска.
Хочу рассказать о наблюдаемом мной парадоксе этой технологии с точки зрения IT и обычной жизни.
Этот термин состоит из конкатенации двух слов: hash и tag. Hash - это прежде всего понятие про уникальность с шифрованием.
Изначально, для того, чтобы добиться создания строки, которая точно будет отличаться от других, программисты придумали различные хэш-функции, которые на вход получали исходные данные, добавляли к ним какие-то индивидуальные или уникальные свойства, и с помощью арифметических вычислений и преобразований строк получали на выходе строку, которая являлась кандидатом на полную уникальность.
Такие функции не всегда могут однозначно давать уникальные ответы в виде строк, поэтому существуют так называемые коллизии.
Короче, здесь главный приоритет - уникальность, "не как у других".
Тег, или тэг - это обозначение какой-то метки.
В HTML используются теги верстки, в разработке через систему контроля версий тегами помечали стабильную версию кода. tag-1.2.3
В общем, эти два термина несут окрас, который применяется во многих отраслях разработки.
Вместо объёмной теории, которой в интернете и так достаточно, держите чеклисты! Ниже представлены чеклисты по оптимизации сайта под SEO и GEO (AI-режим поиска) в виде таблиц: поэтапно, без воды, с приоритетами и инструментами проверки. Скопировать таблицы в Excel / Markdown можно на сайте.
С тех пор как мы представили инструмент резервного копирования в Manticore Search 6, создавать резервные копии данных стало заметно проще. Но мы постоянно слышали один и тот же вопрос: "А как насчёт облачного хранилища?" Сегодня мы рады объявить, что manticore-backup теперь поддерживает S3-совместимое хранилище с потоковой загрузкой — без промежуточных файлов, без проблем с местом на локальном диске, только бэкапы напрямую в облако.
Представьте, что вы создаёте мощное поисковое приложение. Пользователи вводят ключевые слова, а ваш бэкенд должен выполнять запрос к базе данных Manticore Search, чтобы найти подходящие результаты. Распространённый (и соблазнительный!) подход — напрямую вставлять ввод пользователя в SQL‑запросы. Например, вы можете фильтровать по числовому полю, такому как категория или идентификатор записи. Если пользователь передаёт обычное значение, например 5, запрос будет SELECT FROM products WHERE id=5. А что, если он передаст 1 OR 1=1? Запрос станет SELECT FROM products WHERE id=1 OR 1=1 — условие всегда истинно, поэтому запрос вернёт все строки вместо одной. Это SQL‑инъекция.
К счастью, существует более безопасный и эффективный способ: prepared statements. По сути, prepared statements отделяют ваш SQL‑код от передаваемых данных. Вместо того чтобы каждый раз собирать всю строку запроса, вы один раз задаёте структуру запроса с маркерами параметров, а затем отдельно передаёте поисковые термины. Подробнее о концепции можно узнать на Wikipedia .
Manticore Search поддерживает prepared statements через стандартный протокол MySQL, предоставляя мощный инструмент для создания безопасных поисковых приложений. Используя prepared statements, вы не только значительно снизите риск SQL‑инъекций, но и улучшите читаемость вашего кода.
prepared statements — это не просто функция; иногда они являются обязательными. Например, библиотека Rust sqlx работает с MySQL-эндпоинтом, используя исключительно prepared statements. Кроме того, некоторые OLE DB‑коннекторы, позволяющие MS SQL работать с сервером MySQL, тоже используют prepared statements внутри.
Вы слышали, что Manticore Search быстрый. Вы слышали, что он объединяет полнотекстовый, векторный и нечеткий поиск в одном движке. Но когда вы начинаете реально работать с ним, вы сидите перед документацией, угадываете синтаксис SQL и надеетесь, что CREATE TABLE не выдаст непонятную ошибку.
MCP-Manticore меняет правила игры.
Это сервер Model Context Protocol (MCP), который подключает Cursor, Claude Code, Codex CLI или любой другой MCP-совместимый AI-ассистент напрямую к вашему экземпляру Manticore. AI может:
В наше время уже никого не удивишь разработкой агентов, очередной оптимизацией, новой моделью или новой инфраструктурой для нейронок. Всё это в порядке вещей. Однако одно дело читать в Twitter «мы написали агента X и он оптимизировал нам процессы на 300000%», и совсем другое — начать копать чуть глубже. Копнёшь — а «агентом» называют скилл с одним промптом.
Разработка настоящих агентов — задача не тривиальная. Достаточно посмотреть на утёкшие исходники Claude CLI — это не просто CLI, а целая инфраструктура бизнес-логики вокруг LLM. Я бы сравнил разработку агентов с разработкой типичных бэкенд-компонентов. Аналогия такая: если вы пишете каноничный бэкенд-сервис — вам нужна СУБД. Если Web3-сервис — блокчейн. Но на СУБД или блокчейне происходит в лучшем случае 50% всей логики. Вся магия крутится именно на бэкенде. С агентами то же самое: подключаешь AI SDK, конфигурируешь мыслительное ядро и пишешь вокруг него всю обвязку — мониторинги, AIOps, оркестрацию, memory management.
Вот про memory management и пойдёт речь.
Поиск редко сводится к одному универсальному сценарию. Пользователь, вводящий "cheap running shoes", хочет точных совпадений по ключевым словам, а пользователь, задающий "comfortable footwear for jogging", выражает то же намерение другими словами. Традиционный полнотекстовый поиск хорошо справляется с первым случаем. Векторный поиск решает второй. Гибридный поиск объединяет оба в одном запросе, так что вам не приходится выбирать.
В современных поисковых системах это часто описывается как комбинирование лексического (разреженного) поиска с семантическим (плотным) поиском. Разные термины, одна идея: точное совпадение плюс смысл.
Я запустил сайт. Не шаблон на Tilda, не одностраничник на Notion - полноценный статический сайт на Astro, с блогом, лендингом продукта и двумя языками. И прежде чем написать первую статью в блог, я потратил непропорционально много времени на то, чтобы этот сайт правильно видели поисковики - и, что важнее, языковые модели.
Эта статья - о том, что я настраивал, зачем, и почему в 2026 году одного SEO уже недостаточно.
Вы спрашиваете нейросеть — она идёт в интернет и возвращает ответ. Но в какой именно интернет?
Claude ищет через Brave. ChatGPT — через Bing. Gemini — через Google. Три разных поисковых движка, три разных среза, совпадение результатов около 20%.
Я выстроил подход к AI-ресёрчу вокруг этого факта: три уровня, от быстрого вопроса до триангуляции через все три движка. И всё равно нарвался: два AI синхронно соврали.
Плюс бонус-левел: что делать, когда весь интернет врёт и нужен хирургический скальпель вместо широкого поиска.
Сегодня обсудим развёртывание агентов, созданных в Yandex Cloud AI Studio Agent Atelier. Atelier — это такой очевидный UI для настройки PromptTemplate для Responses API.
За последние шесть лет я прошёл через дюжину проектов, связанных с поиском. Роднило их немногое, кроме того, что практически в каждом я обнаруживал одни и те же ошибки. Не сговариваясь, разные команды спотыкались в одних и тех же местах. Эта статья — каталог самых живучих ошибок при проектировании поиска, кочующих из проекта в проект. Примеры построены на ElasticSearch, но большинство пунктов применимы к любому поисковому стеку.
Статья будет полезна как тем, кто еще не делал поисковых систем и столкнулся с проблемой “чистого листа”, так и тем, кто уже имеет какой-то поиск и нутром чует неладное, но не может понять, что не так.
А чтобы было интереснее и веселее, разбирать ошибки мы будем в формате вредных советов, следование которым гарантированно испортит UX ваших пользователей и сделает поиск по вашему ресурсу бесполезным, ненадежным и ужасно дорогим.
Привет! Меня зовут Дмитрий, я ведущий разработчик в команде рекламного рантайма. Наша команда, как вы уже могли догадаться, занимается разработкой аукционов в поисковой рекламе Ozon.
В этой статье я хочу познакомить вас с механикой аукционов и рассказать, как мы делаем это в Ozon. Сначала мы разберёмся, что такое рекламный аукцион, что он имеет общего с аукционом в обычном понимании и как используется в контексте поисковой рекламы. А ещё подробно разберём аукцион типа VCG (аукцион Викри — Кларка — Гровса), вместе выведем формулы для него и посмотрим, какие результаты мы получили на практике.
Лавинообразный рост информации превратил привычный Ctrl+F в артефакт прошлого. Мы открываем тяжёлые PDF-файлы, зарываемся в десятки вкладок, пытаясь выудить одну нужную строчку, и тратим на это часы, которых и так вечно не хватает.
Но времена меняются. На смену ручному поиску приходят умные сервисы, которые умеют не просто искать, а анализировать, обобщать и выдавать готовую выжимку по запросу. Они работают с веб-страницами, документами, научными статьями, а иногда и с тем и другим одновременно.
В этом обзоре мы собрали самых интересных игроков на этом поле:
• BotHub,
• Brave Search,
• ChatPDF,
• “ГигаЧат”,
• Felo AI,
• iAsk,
• Komo,
• Perplexity
• и DuckDuckGo –
Всё, чтобы вы могли выбрать идеальный инструмент для своей задачи – будь то быстрый ответ или глубокое исследование. Готовьте свои самые сложные документы и вопросы – сейчас будем разбираться, кто из них действительно умеет искать иголку в стоге сена. Узнайте, как превратить хаос информации в стройную систему с помощью ИИ.
Когда врач ищет клинические рекомендации, ему обычно нужен не весь PDF, а конкретный фрагмент: схема лечения, критерии диагностики, раздел для детей или взрослых, связь с МКБ-10.
На этом месте официальный рубрикатор и обычный поиск по документам начинают проигрывать реальному сценарию. В статье разбираю задачу с инженерной точки зрения: почему одного каталога недостаточно, зачем нужны нормализация, версионирование, гибридный поиск, офлайн-кэш и ссылки на источник. На примере клинических рекомендаций Минздрава РФ показываю, как медицинская задача превращается в вполне классическую IT-проблему: парсинг, индексирование, поиск по сущностям и объяснимый UX.
С инженерной точки зрения это важное наблюдение: перед нами не одна задача поиска, а сразу несколько разных сценариев, которые нельзя нормально закрыть одним полем search над набором документов.
Официальный источник, от которого все начинается, существует: это электронный рубрикатор клинических рекомендаций Минздрава. На ресурс Минздрава публикуются клинические рекомендации, разработанные и утвержденные медицинскими профессиональными некоммерческими организациями; сам Минздрав отдельно указывает, что этот контент предназначен для медицинских и фармацевтических работников. Кроме того, в инфраструктуре Минздрава есть отдельная автоматизированная подсистема, связанная с разработкой стандартов медпомощи и электронным рубрикатором клинических рекомендаций.
