Как встроить ИИ-поиск в приложение с эмбеддингами

Проверено 20 июля 2026 года. ИИ-поиск с эмбеддингами внедряют как измеряемый конвейер: документы очищают и делят на фрагменты, строят dense-векторы, сохраняют текст и метаданные, извлекают кандидатов, при необходимости объединяют результат с BM25 и оценивают качество на размеченных запросах. Выбор векторной базы вторичен, пока нет тестового набора и метрики.

Минимальный search pipeline

1. Ingestion. Извлечь текст, сохранить URL, заголовок, дату и права доступа.
2. Chunking. Делить по структуре документа и хранить связь с исходником.
3. Embedding. Строить векторы одной зафиксированной моделью.
4. Retrieval. Получать top-k кандидатов с фильтрами доступа.
5. Hybrid. При запросах с артикулами, кодами и именами добавлять лексический поиск.
6. Evaluation. Считать качество на запросах с заранее известными релевантными документами.

При смене модели эмбеддингов коллекцию обычно нужно переиндексировать. Храните имя модели и версию рядом с вектором, иначе две несовместимые системы координат легко окажутся в одной коллекции.

Маленький тестовый набор

documents = {
    "d1": "Сброс пароля выполняется в разделе Безопасность",
    "d2": "Счёт можно скачать в разделе Платежи",
    "d3": "Лимит API меняется администратором проекта",
    "d4": "Экспорт данных доступен в формате CSV",
    "d5": "Двухфакторная аутентификация поддерживает TOTP",
    "d6": "Статус сервиса публикуется на status.example.com",
}

queries = {
    "как получить инвойс": {"d2"},
    "где увеличить квоту запросов": {"d3"},
    "как включить 2FA": {"d5"},
}

Этот набор мал для продуктового решения, но подходит для проверки кода: ingestion не теряет ID, поиск возвращает ожидаемый документ, а метрика считается правильно. Затем замените его 50–200 реальными запросами из логов и разметьте несколько релевантных документов для каждого.

Precision@k и MRR без тяжёлого фреймворка

def precision_at_k(ranked_ids, relevant_ids, k):
    top = ranked_ids[:k]
    return sum(doc_id in relevant_ids for doc_id in top) / k

def reciprocal_rank(ranked_ids, relevant_ids):
    for rank, doc_id in enumerate(ranked_ids, start=1):
        if doc_id in relevant_ids:
            return 1 / rank
    return 0.0

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

Dense или hybrid search

Гибрид не гарантирует улучшение. Сравнивайте dense, sparse и hybrid на одном наборе, затем выбирайте простейший вариант, который проходит порог качества и задержки.

Проверка перед продакшеном

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

Частые вопросы

Нужна ли отдельная векторная база?

Не всегда. Для небольшого проекта подходит расширение существующей БД или локальный индекс. Выбор зависит от фильтров, обновлений, объёма и эксплуатации.

Какой размер чанка лучший?

Универсального числа нет. Сравните несколько вариантов на своей разметке и учитывайте структуру документов.

Косинусная близость равна релевантности?

Нет. Это сигнал модели эмбеддингов. Пользовательская релевантность также зависит от свежести, прав доступа, типа документа и задачи.

Когда нужен reranker?

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

Источники и дата проверки

• Официальная карточка text-embedding-3-large.
• Qdrant: Hybrid Search with Reranking.
• Qdrant: Hybrid Queries.
• Первичная публикация о RAG.

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

• RAG: как подключить документы к модели
• LangChain и LlamaIndex
• Как развернуть vLLM

Сохранённые ссылки эксперимента

• векторных баз данных
• разбор векторных баз данных