Знаете, что бесит в современных поисковиках? Ты печатаешь сложный запрос — и получаешь ссылки, которые даже не касаются сути. А если это вопрос вроде «как повлияет изменение ставки ЦБ на ипотеку в 2026 году?» — классический поиск разводит руками. VK в своей новой платформе Discovery AI решили пойти ва-банк: объединить традиционный поиск с LLM так, чтобы ответ приходил быстрее, чем вы моргнете. Под капотом — гибридная архитектура, которая жертвует глубиной на этапе поиска, но выигрывает за счет интеллектуального ранжирования и генерации. Рассказываю, как это устроено и почему у них получилось держать latency <500 мс.

Дисклеймер: Я не сотрудник VK и не участвовал в разработке Discovery AI. Статья основана на публичных докладах, открытых данных и личном опыте оптимизации поисковых систем. Все цифры — из официальных источников VK на июнь 2026 года.

Проблема: RAG врал, поиск тупил

Когда RAG-системы только появились, все думали: «Ну, теперь-то LLM будет отвечать на основе релевантных документов, и никаких галлюцинаций». На практике оказалось иначе. Пока база знаний маленькая — всё ок. Как только документов становится >100k, качество падает. Почему? Потому что семантический поиск на эмбеддингах не гарантирует релевантности: он находит «похожие» векторы, но не факт, что они содержат правильный ответ. В статье про деградацию RAG мы разбирали, как рост коллекции убивает точность — это та же проблема, с которой столкнулись VK.

В Discovery AI решили не полагаться на один метод. Они взяли лучшее из двух миров: быстрый ANN-поиск по эмбеддингам для первого прохода и мощный BERT-реранкер для второго, а затем еще и LLM для синтеза ответа. Но как уложиться в 500 мс, если один вызов LLM может занимать секунду? Ответ — каскадная архитектура с жёсткими таймаутами и распределением нагрузки.

Решение: каскад «Поиск → Реранк → Генерация»

Архитектура Discovery AI — это три последовательных этапа, каждый из которых может застопиться, если не укладывается в лимит. Время на весь пайплайн — 450 мс (с запасом 50 мс на сеть и декодинг).

1 Этап поиска: ANN + BM25 (50 мс)

Первым делом запрос кодируется в эмбеддинг с помощью lightweight-модели на базе MiniLM-L6 (квантизированная до INT8). Затем идёт параллельный поиск по двум индексам: ANN на основе HNSW (FAISS) и BM25 (через Tantivy). ANN даёт семантическую близость, BM25 — точное совпадение ключевых слов. Результаты обоих методов смешиваются с весами: 60% ANN + 40% BM25. Top-200 документов передаются на следующий этап. Время — строго 50 мс; если не успели, берём то, что есть.

Важно: Изначально VK хотели использовать только ANN, но тесты показали, что для коротких запросов (например, «VK футбол 2026») BM25 даёт лучшие результаты. Гибрид — компромисс, который, впрочем, добавил 10 мс к latency. Иногда лучшее — враг хорошего.

2 Этап реранкинга: BERT на стероидах (150 мс)

200 кандидатов — это много. Чтобы понять, какие из них действительно отвечают на вопрос, нужна более глубокая модель. VK используют дообученную версию ruRoberta-large с cross-encoder архитектурой. Модель обрабатывает пары (запрос, документ) и выдаёт score релевантности. Но 200 пар — это долго. Решение — пакетная обработка: GPU может обработать 32 пары за один forward pass. Но даже так latency ~150 мс. Чтобы ускорить, применили:

Dynamic batching — запросы от разных пользователей группируются в батч.
ONNX Runtime с оптимизацией под TensorRT — модель работает в 2.5x быстрее, чем PyTorch eager.
Отбрасывание кандидатов — если модель даёт очень низкий score, документ отбрасывается досрочно (early exit).

В итоге топ-10 документов с наивысшими scores передаются LLM. Кстати, про оптимизацию инференса: в статье «Поиск для AI-агентов: сжимаем латентность с 3500 мс до 700 мс» мы разбирали похожие приёмы — dynamic batching и квантизацию.

3 Этап генерации: LLM с помощником Deep Research (200 мс)

Финальный этап — LLM должна на основе топ-10 документов сформулировать ответ. Здесь VK пошли по пути агентного сценария Deep Research: модель-рассуждалка анализирует документы, выделяет ключевые факты и формирует связный ответ. В базе используется VK-LLM-78B (собственная модель VK на базе архитектуры DeepSeek V3 с 256k контекстом). Но как уложиться в 200 мс, если модель большая? Секрет в том, что на этапе генерации не всегда используется полная LLM. Если запрос фактологический и ответ можно извлечь из одного документа — срабатывает лёгкая T5-small (50 мс). Если нужен сложный синтез — запускается 78B, но с ограничением по токенам (максимум 128 токенов ответа). Для ещё более сложных запросов (например, «сравни две статьи») активируется агент Deep Research, который делает несколько итераций поиска — но такой запрос уже может занимать 2-3 секунды (и пользователь получает промежуточный прогресс).

VK вдохновлялись OpenSeeker-v2 — открытым агентом Deep Research, который показывает, что итеративный сбор информации с ранним выходом даёт лучший результат, чем однопроходная генерация.

Оптимизация latency: где прячутся миллисекунды

Чтобы держать <500 мс, VK пришлось вылизывать каждый этап. Вот ключевые фишки, которые могут пригодиться любому разработчику поиска:

Квантизация моделей. Все энкодеры и реранкеры — INT8. Потери в качестве <1% по MRR, но прирост скорости 4x.
KV-cache на стороне LLM. Для частых запросов (например, «погода в Москве») кэшируется состояние трансформера, что сокращает prefill в 3 раза.
Асинхронные пайплайны. Этапы поиска и реранкинга запускаются на разных GPU, данные передаются через RDMA — так избегаем блокировок.
Predictive pre-fetching. Если модель Deep Research запросила больше документов, система предзагружает топ-50 кандидатов следующего этапа, пока текущий ещё не закончен.

💡

Обратите внимание на статью «BM25 против нейросетей: как antaris-memory ускоряет память агентов в 50 раз» — там показан альтернативный подход к кэшированию, который может быть интегрирован в любой пайплайн.

Гетерогенные данные: как искать не только текст

Discovery AI изначально затачивался под мультимедийный контент VK: текст постов, изображения, видео, таблицы. Для каждого типа данных — свой энкодер (CLIP для картинок, Whisper для аудио, специальный табличный трансформер). Эмбеддинги всех модальностей приводятся к единому векторному пространству через проекционный слой. На этапе реранкинга cross-encoder умеет принимать не только текст, но и визуальные признаки (если документ — картинка, то в модель подаётся caption + эмбеддинг изображения).

Это добавляет сложности в индексацию, но зато пользователь может спросить «найди фото кота в шляпе, похожее на этот мем» — и система найдёт.

Нюансы, о которых молчат презентации

У любой красивой архитектуры есть подводные камни. Вот три, которые VK пришлось решать в боевых условиях:

Холодный старт для новых документов. Если документ только залили, у него нет эмбеддинга. Discovery AI использует потоковую индексацию: документ сразу попадает в BM25-индекс, а эмбеддинг вычисляется асинхронно в течение 1 секунды. Но первые запросы могут его не найти. Решение — fallback на BM25-only для свежих документов.
Стоимость инференса. 78B-модель на каждые 1000 запросов — это примерно 1 час работы H100. VK снижают затраты через speculative decoding и offloading на CPU для непиковых часов. Но всё равно дорого. Поэтому они ввели tiered pricing для API: быстрые ответы (LLM-синтез) стоят дороже, а только поиск — дёшево.
Latency сети. Если дата-центры в разных регионах, RTT может добавить 50-100 мс. VK развернули инференс на edge-узлах внутри своей CDN. Для особо чувствительных запросов (например, поиск по сообщениям) поднимают легковесные модели прямо на клиенте (через WebLLM и ONNX в браузере).

Три типичные ошибки при построении нейропоиска

Если вы решите повторить подобное (а наверняка захотите), вот чего делать точно не стоит:

Не использовать кэширование результатов поиска. Если пользователи задают одинаковые вопросы, вы будете каждый раз гонять ANN и BM25. VK кэшируют результаты первых двух этапов на 5 минут — это снижает нагрузку на 40%. Пример из жизни: один стартап, с которым я консультировал, забыл про кэш и удивлялся, почему H100 греется как печка.
Игнорировать колокацию данных и моделей. Если ANN-индекс лежит на отдельном сервере, а реранкер — на другом, вы будете тратить время на передачу 200 документов. VK разместили всё на одном узле с NVLink — latency межсоединения <1 мкс.
Не ограничивать длину ответа LLM. LLM может сгенерировать много токенов, что убивает latency. Ставьте жёсткий лимит (128 токенов для быстрого режима) и используйте стриминг: первый токен отдаётся клиенту через 50 мс, остальные догружаются. Пользователь уже видит начало ответа.

В целом, архитектура Discovery AI — это не серебряная пуля. Это прагматичный компромисс между качеством, скоростью и стоимостью. Если вам нужна сверхточная аналитика — придётся ждать 2-3 секунды. Если хотите «просто найти» — 500 мс хватит. VK, кстати, не скрывают, что для некоторых сценариев (например, Deep Research с многошаговым сбором данных) задержка может достигать 5 секунд — но они прозрачно показывают пользователю прогресс.

Мой совет: если вы строите нейропоиск для своего продукта — не гонитесь за столь жёсткими лимитами, как VK. 500 мс — это бар, который оправдан только для массового потребителя, где каждая миллисекунда равна потере денег. Для внутренних систем, корпоративных баз знаний, агентных RAG (читайте «Поиск для AI-агентов») часто хватает 1-2 секунд. Лучше потратьте бюджет на качество реранкера и чистоту индекса, чем на вылизывание миллисекунд. Поверьте, пользователь простит лишнюю секунду, но не простит глупый ответ.

Подписаться на канал

Архитектура нейропоиска Discovery AI от VK: как объединить LLM и поиск с задержкой <500 мс