AI-поиск

Что такое AI-поиск

AI-поиск (AI search) — поиск, который находит документы по смыслу запроса, а не по совпадению слов, и нередко возвращает готовый ответ вместо списка ссылок. Спросите «почему сервер не отвечает» — и найдётся статья про таймауты соединения, где нет ни слова «сервер», ни слова «отвечает».

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

Три подхода к поиску

Ключевой вывод из таблицы: векторный поиск не заменяет keyword-поиск. Он проваливается ровно там, где keyword силён — на точных совпадениях: артикул RTX-4090-24G или номер договора векторно найдут что-то «похожее по смыслу», то есть не то. Поэтому в продакшене почти всегда используют гибрид, объединяя два списка результатов (обычно через Reciprocal Rank Fusion).

Как это устроено

Индексация (заранее)
────────────────────
Документы → нарезка на чанки → модель эмбеддингов → векторы → индекс

Запрос (в реальном времени)
───────────────────────────
Запрос пользователя
    ↓
Эмбеддинг запроса
    ↓
ANN-поиск ближайших векторов  →  top-50 кандидатов
    ↓
Reranker (cross-encoder)      →  top-5 лучших
    ↓
LLM формулирует ответ по найденным фрагментам
    ↓
Ответ + ссылки на источники

Последние два шага — то, что называют RAG (retrieval-augmented generation): LLM отвечает не по своим внутренним знаниям, а по найденным документам. Это решает две проблемы разом — модель получает свежие и приватные данные, которых не было в обучении, и может сослаться на источник.

Компоненты

• Модель эмбеддингов — превращает текст в вектор. Для русского языка берут мультиязычные модели (E5, BGE); размерность обычно 384–1024.
• Нарезка на чанки — документы режут на фрагменты по 200–500 токенов. Слишком крупные чанки размывают смысл вектора, слишком мелкие теряют контекст. Это первое, что стоит настраивать, если качество поиска низкое.
• Векторный индекс — ANN-поиск (HNSW, IVF) находит ближайшие векторы приближённо, но за миллисекунды вместо перебора всей базы.
• Reranker — cross-encoder, который заново оценивает top-50 кандидатов, читая запрос и документ вместе. Медленнее эмбеддингов, поэтому применяется только к отобранным кандидатам, зато заметно поднимает точность.

Где хранить векторы

Отдельная векторная БД (Qdrant, Milvus, Weaviate) нужна далеко не всегда. Если документов десятки или сотни тысяч, расширение pgvector для PostgreSQL закрывает задачу: векторы лежат рядом с бизнес-данными, работают привычные транзакции и бэкапы, а гибридный поиск делается одним запросом вместе с полнотекстовым.

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

Метрики качества

• recall@k — доля случаев, когда нужный документ попал в первые k результатов. Главная метрика этапа поиска: если документа нет в кандидатах, никакой reranker и никакая LLM его не спасут.
• MRR / NDCG — учитывают, на какой позиции оказался правильный ответ.
• Точность ответа — оценивают отдельно: отвечает ли LLM строго по найденным фрагментам и не выдумывает ли лишнего.

Диагностика идёт сверху вниз: сначала измеряют recall поиска, и только потом качество ответа. Плохой ответ при плохом recall — проблема поиска, а не модели.

Инфраструктура

Своё железо в AI-поиске нужно по двум причинам: приватность (индексируется внутренняя документация, переписка, договоры) и объём — эмбеддинги считаются для всей базы документов, а не только для запросов.

• Индексация — разовая пакетная нагрузка. Модель эмбеддингов небольшая, помещается в несколько ГБ VRAM; скорость упирается в throughput, поэтому помогает батчинг.
• Запросы — эмбеддинг одного запроса и реранк top-50 считаются за миллисекунды. Здесь важна латентность.
• Генерация ответа — самая тяжёлая часть: нужен инференс LLM. Найденные фрагменты подаются в промпт, поэтому следите за контекстным окном — десяток чанков легко съедает тысячи токенов.

Эмбеддер и LLM удобно разносить: первый — небольшая карта под постоянную нагрузку, второй — под генерацию.

Связанные термины

• эмбеддинг — основа поиска по смыслу
• LLM — формулирует ответ по найденным документам
• NLP — область, к которой относится задача
• контекстное окно — предел на объём подставляемых фрагментов
• PostgreSQL — pgvector как рабочее хранилище векторов
• инференс — запуск моделей эмбеддингов и генерации