Эмбеддинги и семантический поиск для бизнеса

Корпоративная база знаний из 5 000 документов бесполезна, если сотрудник не находит нужный раздел за 30 секунд. Семантический поиск ИИ на основе эмбеддингов решает это иначе: клиент пишет «хочу вернуть заказ», система находит раздел «процедура возврата» без единого совпадающего слова. ИИ переводит текст в числовые векторы и ищет по смысловой близости. Запустить такой поиск по корпоративным документам можно за 1–2 дня без ML-специалиста в штате.

Что такое эмбеддинги и зачем они нужны бизнесу

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

Слова «автомобиль», «машина» и «авто» получат близкие векторы, хотя написание разное. «Автомобиль» и «морковь» окажутся на разных полюсах. На этом и строится современный семантический поиск.

На практике три сценария, где это меняет работу:

• База знаний поддержки. Клиент задаёт вопрос в свободной форме, система находит релевантный ответ из 10 000 FAQ-статей, даже если формулировка совершенно другая.
• Поиск по внутренним документам. Сотрудник вводит «какой порядок согласования командировок» и получает нужный регламент, а не список всех файлов со словом «командировка».
• Чат-бот на корпоративных данных. LLM отвечает на вопросы, опираясь на реальные данные компании (RAG-архитектура). Галлюцинаций нет: каждый ответ привязан к источнику.

Семантический поиск vs обычный: в чём разница

Классический полнотекстовый поиск (BM25, LIKE-запросы в SQL) сравнивает слова: ищет точное или частичное совпадение токенов. Работает нормально, пока пользователь точно знает термин. Но большинство людей формулируют запросы иначе, чем написаны документы.

Семантический поиск устроен иначе:

1. Документы базы знаний заранее переводятся в эмбеддинги и сохраняются в векторной базе данных.
2. Запрос пользователя конвертируется в эмбеддинг той же моделью.
3. Система находит документы, чьи векторы ближе всего к вектору запроса (косинусное расстояние).
4. Топ-3 или топ-5 релевантных фрагментов передаются в LLM для генерации ответа.

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

Гибридный поиск объединяет оба подхода: семантический покрывает смысловые запросы, BM25 точно находит числа, артикулы и имена. Большинство production-систем используют именно эту связку.

Когда бизнесу нужен семантический поиск

Стандартный поиск начинает подводить в одних и тех же ситуациях. Пользователи уточняют запросы по 3–4 раза, прежде чем найдут нужное. Support вручную отвечает на вопросы, ответы на которые давно есть в базе. База знаний переросла 500 статей, и навигация по разделам больше не помогает.

Чаще всего семантический поиск внедряют:

• Службы клиентской поддержки с большим FAQ (e-commerce, банки, страхование)
• Юридические и HR-отделы с большим объёмом регламентов и договоров
• Медицинские организации с базами протоколов лечения и препаратов
• Производственные компании с техническими инструкциями и регламентами

Если документов меньше 200, затраты на внедрение не окупятся: обычный поиск справится. При большом объёме структурированных данных (таблицы, числа, коды) сначала попробуйте SQL-поиск с фильтрами.

RAG-архитектура: как всё работает вместе

RAG (Retrieval-Augmented Generation) решает главную проблему корпоративных чат-ботов. Вместо обучающих данных LLM получает доступ к реальным документам компании и отвечает по ним. Галлюцинации пропадают: каждый ответ привязан к конкретному источнику.

Как устроен RAG в production:

1. Индексация. Загрузите документы, разбейте на чанки по 500–1000 токенов с перекрытием. Каждый чанк переводится в эмбеддинг и сохраняется в векторную БД с метаданными: источник, дата, категория.
2. Поиск. Запрос пользователя конвертируется в эмбеддинг, система ищет top-k ближайших чанков в векторной БД.
3. Генерация. LLM получает системный промпт, найденные чанки и вопрос пользователя, затем формирует ответ со ссылкой на источник.
4. Ответ. Пользователь видит ответ и ссылку на исходный документ.

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

Подробнее о том, как выстроить внедрение ИИ в бизнес с RAG-архитектурой, читайте в разделе услуг.

Как подключить семантический поиск к базе знаний: пошаговый план

Шаг 1. Подготовка документов. Соберите исходники в один формат: PDF, Word, Markdown, HTML. Разбейте текст на чанки по 500–800 токенов (200–400 слов) с перекрытием 50–100 токенов: перекрытие сохраняет контекст на границах. Для Python используйте langchain.text_splitter.RecursiveCharacterTextSplitter.

Шаг 2. Выбор и подключение embedding-модели. Выберите провайдера (см. следующий раздел). Получите API-ключ. Для каждого чанка вызовите API и сохраните вектор. Пример для YandexGPT Embeddings:

import requests

def get_embedding(text: str, folder_id: str, api_key: str) -> list[float]:
    resp = requests.post(
        "https://llm.api.cloud.yandex.net/foundationModels/v1/textEmbedding",
        headers={"Authorization": f"Api-Key {api_key}"},
        json={
            "modelUri": f"emb://{folder_id}/text-search-doc/latest",
            "text": text
        }
    )
    return resp.json()["embedding"]

Шаг 3. Векторная база данных. Запустите Qdrant в Docker:

docker run -p 6333:6333 qdrant/qdrant

Создайте коллекцию и добавьте векторы чанков с метаданными (source_url, chunk_id, text). Qdrant хранит и вектор, и JSON-пейлоад с исходным текстом: именно этот текст потом передаётся в LLM как контекст.

Шаг 4. Поисковый эндпоинт. При запросе: конвертируйте запрос в эмбеддинг, ищите top-5 в Qdrant, передайте найденные тексты в LLM и верните ответ с источниками.

Шаг 5. Тестирование и настройка. Прогоните 20–30 реальных запросов. Если релевантность низкая: увеличьте overlap между чанками, смените модель эмбеддингов или добавьте BM25 для гибридного поиска. Recall@5 выше 80% считается рабочим порогом для уверенного старта в продакшне.

Выбор embedding-модели: OpenAI, YandexGPT или open-source

Для русскоязычного контента:

• YandexGPT Embeddings: 0,06 ₽ за 1 000 токенов (search-doc модель), данные остаются в РФ, соответствие 152-ФЗ. Хорошо работает на деловом русском. Основной минус: нет community-поддержки уровня OpenAI.
• OpenAI text-embedding-3-small: $0,02 за 1 000 000 токенов (около 1,8 ₽). Лучшее соотношение цена/качество по международным бенчмаркам MTEB. Данные уходят на серверы в США, что создаёт риск при работе с персональными данными.
• OpenAI text-embedding-3-large: $0,13 за млн токенов. Максимальное качество, размерность 3 072 (против 1 536 у small). Оправдан для сложных нишевых документов.
• multilingual-e5-large: open-source (HuggingFace), self-hosted. Хорошо работает с русским, без внешних зависимостей. Требует GPU или мощного CPU.
• bge-m3: сильнейшая open-source модель по MTEB 2026, поддерживает dense+sparse+multi-vector поиск. Self-hosted, 570M параметров.

Если обрабатываете персональные данные и хотите остаться в российском контуре, начните с YandexGPT Embeddings. Для прототипа без персданных подойдёт OpenAI text-embedding-3-small.

Стоимость: считаем реальный бюджет

Бюджет из трёх строк: разовая индексация, регулярные запросы и инфраструктура.

Индексация базы знаний: разовая операция при первом запуске и при обновлении документов:

• 10 000 чанков по 500 токенов = 5 000 000 токенов
• YandexGPT Embeddings: 5 000 × 0,06 ₽ = 300 ₽ разово
• OpenAI text-embedding-3-small: 5 × $0,02 = $0,10 разово

Поисковые запросы: каждый раз при обращении пользователя:

• 1 000 запросов/мес, 200 токенов на запрос = 200 000 токенов
• YandexGPT: 200 × 0,06 ₽ = 12 ₽/мес
• OpenAI small: 0,2 × $0,02 = $0,004/мес

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

• Qdrant Cloud (бесплатный tier до 1 ГБ): 0 ₽/мес
• Qdrant self-hosted на VPS 2 ГБ RAM: от 500 ₽/мес
• pgvector (расширение PostgreSQL): 0 ₽ доп., если Postgres уже есть

MVP на 10 000 документов и 1 000 запросов/мес обойдётся от 500 ₽/мес (self-hosted Qdrant + YandexGPT embeddings). Backend потребует 40–80 часов разработки. Подробнее об интеграции, читайте в разделе ИИ-агентов и RAG-сервисов.

Типичные ошибки при внедрении

Слишком маленькие чанки. Чанки по 50–100 токенов теряют контекст: вектор описывает фрагмент без смысла. Минимум 200–300 токенов, оптимально 500–800.

Одна модель для документов и запросов. Для индексации и поиска нужны разные режимы. YandexGPT Embeddings предоставляет две модели: text-search-doc для документов и text-search-query для запросов. Перепутаете: качество заметно упадёт.

Пропуск гибридного поиска. Чисто семантический поиск плохо находит точные числа, имена и артикулы. Комбинация с BM25 (через Qdrant sparse vectors или Elasticsearch) даёт +15–25% точности на смешанных запросах.

Полная переиндексация при каждом обновлении. При изменении одного документа переиндексируйте только изменённые чанки. Это снижает затраты на 90% при регулярных обновлениях базы.

Отсутствие мониторинга после запуска. Система заработала, запросы идут, но никто не измеряет, насколько точно она отвечает. Стандартная метрика: Recall@5, то есть система должна находить нужный документ в пяти верхних результатах как минимум в 8 случаях из 10. Если показатель ниже 70%, пора менять стратегию: пересмотреть размер чанков, сменить embedding-модель или добавить гибридный поиск. Для контроля качества: qdrant-client логирует запросы и результаты, библиотека RAGAS автоматически оценивает faithfulness и relevancy ответов RAG-системы. Заведите список из 50 тестовых вопросов с эталонными ответами и прогоняйте его при каждом изменении конфигурации. Хорошая новость: тесты обычно занимают меньше минуты на 50 вопросов. Без этого деградация точности может оставаться незамеченной месяцами, пока пользователи не начнут жаловаться на качество ответов.