RAG и базы знаний beginner 13 мин

Что такое embeddings и как ИИ ищет по смыслу

Простое объяснение embeddings: как текст превращается в векторы, зачем нужен semantic search, как embeddings работают в RAG, рекомендациях и поиске по документам.

RAG embeddings vector database основы AI эмбеддинги semantic search

Короткое объяснение

Embeddings, или эмбеддинги, - это числовые представления текста, изображения, товара, документа или другого объекта. Они помогают ИИ сравнивать объекты по смысловой близости, а не только по точному совпадению слов.

Если совсем просто:

  1. текст превращают в список чисел;
  2. похожие по смыслу тексты получают похожие списки чисел;
  3. эти списки можно сравнивать;
  4. система находит ближайшие фрагменты;
  5. найденные фрагменты можно передать LLM как контекст.

Именно поэтому RAG может найти документ с фразой “оформление возврата”, даже если пользователь спрашивает “как вернуть товар”.

Зачем нужны embeddings

Обычный поиск по словам хорошо работает, когда пользователь пишет те же слова, что есть в документе. Но в реальности люди формулируют вопросы по-разному.

Пример:

  1. в базе написано “приостановка подписки”;
  2. пользователь спрашивает “как временно отключить тариф”;
  3. точных слов мало;
  4. смысл похожий;
  5. embeddings помогают найти нужный фрагмент.

Embeddings нужны там, где важно искать по смыслу, группировать похожие тексты, находить дубли, строить рекомендации и подключать документы к ИИ-ответам.

Как embeddings работают на уровне идеи

Embedding-модель получает текст и возвращает вектор: список чисел фиксированной длины. Эти числа кодируют не буквы напрямую, а признаки смысла, стиля, темы и контекста.

Упрощенно:

  1. текст отправляют в embedding-модель;
  2. модель превращает его в вектор;
  3. вектор сохраняют в базу;
  4. новый вопрос тоже превращают в вектор;
  5. система ищет ближайшие векторы;
  6. ближайшие тексты считаются похожими по смыслу.

Человеку такой список чисел ничего не говорит. Но для машины это удобный способ сравнивать смыслы.

Что такое вектор

Вектор - это список чисел. Например, не настоящий embedding, а грубая иллюстрация:

  1. “возврат товара” -> [0.12, -0.44, 0.91];
  2. “как вернуть покупку” -> [0.10, -0.40, 0.88];
  3. “как приготовить суп” -> [-0.73, 0.15, -0.20].

Первые два вектора ближе друг к другу, потому что тексты похожи по смыслу. Третий далеко, потому что тема другая.

В реальных моделях вектор обычно состоит не из трех чисел, а из сотен или тысяч измерений.

Что значит “поиск по смыслу”

Поиск по смыслу, или semantic search, сравнивает не только слова, а близость смыслов.

Это помогает, когда:

  1. пользователь использует синонимы;
  2. формулировка отличается от документа;
  3. вопрос короткий, а ответ спрятан в длинном разделе;
  4. в тексте нет точного совпадения;
  5. нужно найти похожие идеи;
  6. нужно сгруппировать близкие обращения клиентов;
  7. нужно найти похожие товары или статьи.

Но semantic search не идеален. Для точных номеров, артикулов, имен методов, юридических формулировок и кодов часто нужен еще keyword search.

Embeddings и RAG

В RAG embeddings обычно используются для поиска фрагментов базы знаний.

Типовой процесс:

  1. документы режут на chunks;
  2. каждый chunk превращают в embedding;
  3. embedding и текст сохраняют в векторную базу;
  4. вопрос пользователя тоже превращают в embedding;
  5. база находит ближайшие chunks;
  6. найденные chunks передают модели;
  7. модель отвечает по найденному контексту.

Embeddings в RAG - это не ответ пользователю, а слой поиска. Ответ пишет LLM, но качество ответа сильно зависит от того, какие фрагменты нашли embeddings и retrieval.

Keyword search ищет точные слова. Embeddings ищут смысловую близость.

Keyword search хорош, когда важны:

  1. артикулы;
  2. номера договоров;
  3. названия функций;
  4. точные юридические термины;
  5. имена файлов;
  6. коды ошибок;
  7. уникальные названия.

Embeddings хороши, когда важны:

  1. синонимы;
  2. разные формулировки;
  3. похожие вопросы;
  4. обобщенные темы;
  5. смысловые дубли;
  6. рекомендации;
  7. поиск по длинным документам.

В бизнес-поиске часто используют hybrid search: semantic search плюс keyword search.

Embeddings и векторная база

Векторная база хранит embeddings и умеет быстро искать ближайшие векторы. Без нее можно сделать маленький прототип, но на реальных данных нужна база или индекс.

В векторной базе обычно есть:

  1. embedding;
  2. исходный текст;
  3. id документа;
  4. заголовок;
  5. ссылка на источник;
  6. дата обновления;
  7. права доступа;
  8. тип документа;
  9. язык;
  10. дополнительные метаданные.

Метаданные очень важны. Иначе система может найти правильный по смыслу, но устаревший или запрещенный пользователю документ.

Как измеряют близость embeddings

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

Часто встречаются:

  1. cosine similarity;
  2. dot product;
  3. Euclidean distance;
  4. approximate nearest neighbors;
  5. top k nearest vectors.

Пользователю не нужно знать математику, но важно понимать смысл: система ищет не “идеально такой же текст”, а ближайшие векторы по выбранной метрике.

Что такое top k

Top k - это сколько ближайших результатов система вернет из поиска.

Например:

  1. top k = 3 - вернуть 3 ближайших фрагмента;
  2. top k = 10 - вернуть 10 ближайших фрагментов;
  3. top k = 30 - вернуть 30 кандидатов для reranker.

Если top k слишком маленький, нужный фрагмент может не попасть в контекст. Если слишком большой, модель получит шум и может запутаться.

Для первого RAG часто начинают с top k от 3 до 8, а дальше подбирают по тестам.

Где embeddings применяются

Embeddings полезны не только в RAG.

Примеры:

  1. поиск по базе знаний;
  2. чат по документам;
  3. поиск похожих статей;
  4. рекомендации товаров;
  5. кластеризация обращений клиентов;
  6. поиск дублей;
  7. сравнение резюме и вакансий;
  8. семантический поиск по коду;
  9. поиск похожих изображений;
  10. анализ отзывов;
  11. маршрутизация тикетов;
  12. подбор релевантных FAQ.

Главная идея одна: превратить объекты в векторы и сравнивать их по близости.

Пример для сайта со статьями

На информационном сайте embeddings можно использовать так:

  1. превратить каждую статью или раздел статьи в embedding;
  2. сохранить embedding, заголовок, URL и категорию;
  3. при чтении статьи найти похожие материалы;
  4. в поиске понимать запросы вроде “почему ИИ выдумывает”;
  5. показывать пользователю статьи про галлюцинации, RAG и проверки;
  6. находить темы, которые пересекаются по смыслу.

Так блок “похожие статьи” становится не ручным списком, а смысловой рекомендацией.

Пример для поддержки клиентов

В поддержке embeddings помогают находить ответы, даже если клиент пишет своими словами.

Пример:

  1. клиент пишет: “мне списали деньги, хотя я отменял подписку”;
  2. система ищет похожие фрагменты про отмену, списание и возврат;
  3. находит инструкцию;
  4. модель формирует ответ;
  5. если данных недостаточно, создает задачу оператору.

Без embeddings такой вопрос может не совпасть с точными словами базы знаний.

Пример для аналитики отзывов

Embeddings помогают группировать похожие отзывы.

Например, есть 500 отзывов:

  1. “долго отвечают”;
  2. “поддержка молчит”;
  3. “ответ пришел через два дня”;
  4. “не могу дождаться оператора”.

Слова разные, но смысл близкий. Embeddings помогут собрать их в один кластер: “медленная поддержка”. Это полезно для NPS, customer success и анализа качества сервиса.

Что влияет на качество embeddings

Качество зависит не только от модели.

Важные факторы:

  1. язык документов;
  2. качество embedding-модели;
  3. размер chunks;
  4. чистота текста;
  5. наличие заголовков;
  6. метаданные;
  7. дубли и старые версии;
  8. смешение разных тем в одном chunk;
  9. выбор метрики близости;
  10. top k и reranking;
  11. тестовый набор вопросов;
  12. фильтры доступа.

Если retrieval слабый, сначала проверяйте данные и chunks, а уже потом меняйте LLM.

Почему embeddings могут ошибаться

Embeddings не являются идеальным пониманием смысла.

Ошибки бывают, когда:

  1. запрос слишком короткий;
  2. в документе мало контекста;
  3. используются редкие термины;
  4. важны точные номера и коды;
  5. разные темы похожи словами;
  6. embedding-модель плохо работает с нужным языком;
  7. chunk обрезан в плохом месте;
  8. база содержит устаревшие документы;
  9. нет metadata filtering;
  10. top k настроен неправильно.

Поэтому embeddings нужно тестировать на реальных вопросах, а не только смотреть красивые демо.

Почему embeddings не заменяют LLM

Embeddings помогают найти похожее, но не пишут полноценный ответ. Они не объясняют, не рассуждают, не оформляют вывод и не проверяют бизнес-правила.

Обычно роли такие:

  1. embeddings находят кандидатов;
  2. retriever возвращает chunks;
  3. reranker уточняет порядок;
  4. LLM формирует ответ;
  5. guardrails проверяют ограничения;
  6. человек проверяет рискованные случаи.

Embeddings - это важная часть поиска, а не весь интеллект системы.

Нужно ли хранить embeddings навсегда

Embeddings нужно обновлять, когда меняются исходные документы или embedding-модель.

Пересоздание нужно, если:

  1. текст chunk изменился;
  2. документ удален;
  3. документ стал устаревшим;
  4. изменилась embedding-модель;
  5. изменился способ chunking;
  6. добавлены новые метаданные;
  7. нужно переиндексировать права доступа;
  8. качество retrieval просело.

Если поменять embedding-модель только для новых документов, старая и новая часть индекса могут сравниваться некорректно. Обычно индекс пересобирают полностью или ведут версии.

Приватность и embeddings

Embedding - это не исходный текст, но он все равно связан с данными. Не стоит считать embeddings полностью безопасными.

Что учитывать:

  1. кто создает embeddings;
  2. уходят ли данные во внешний API;
  3. где хранится векторная база;
  4. есть ли права доступа;
  5. можно ли удалить документ и его embedding;
  6. не попали ли в chunks персональные данные;
  7. есть ли логирование запросов;
  8. как обрабатываются секреты;
  9. кто имеет доступ к индексу;
  10. как устроено резервное копирование.

Для чувствительных данных выбирайте подход с учетом политики безопасности: облачный, self-hosted или локальный.

Как выбрать embedding-модель

Выбор зависит от задачи.

Смотрите на:

  1. качество на русском языке;
  2. качество на английском языке;
  3. поддержку многоязычных данных;
  4. стоимость;
  5. скорость;
  6. размер вектора;
  7. лимит входного текста;
  8. возможность self-hosted запуска;
  9. совместимость с вашей векторной базой;
  10. качество на ваших тестовых вопросах.

Главный критерий - не рейтинг в вакууме, а retrieval quality на вашей базе знаний.

Как тестировать embeddings

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

  1. 30-50 реальных вопросов пользователей;
  2. правильный документ для каждого вопроса;
  3. правильный chunk или раздел;
  4. несколько вопросов без ответа;
  5. точные запросы с номерами и кодами;
  6. вопросы с синонимами;
  7. вопросы на русском и английском, если база смешанная;
  8. устаревшие документы;
  9. документы с похожими темами;
  10. проверка прав доступа.

После этого смотрите, попал ли правильный chunk в top 3, top 5 или top 10. Это даст более честную картину, чем один удачный пример.

Типичные ошибки

Частые ошибки при работе с embeddings:

  1. индексируют грязные документы;
  2. режут chunks случайно;
  3. не добавляют заголовки в chunks;
  4. забывают метаданные;
  5. не фильтруют права доступа;
  6. используют только semantic search для точных артикулов;
  7. меняют embedding-модель без пересборки индекса;
  8. не тестируют русские запросы;
  9. отправляют слишком много chunks в LLM;
  10. не проверяют вопросы без ответа;
  11. считают, что embeddings сами решают галлюцинации;
  12. не удаляют embeddings после удаления документа.

Большая часть проблем решается аккуратной подготовкой данных и регулярными evals.

Мини-чеклист

Перед запуском semantic search проверьте:

  1. документы очищены;
  2. chunks сохраняют смысл;
  3. у chunks есть заголовки;
  4. добавлены источники и даты;
  5. есть права доступа;
  6. выбрана embedding-модель;
  7. выбран top k;
  8. настроены метаданные;
  9. есть тестовые вопросы;
  10. результаты проверены на реальных формулировках.

Если все это есть, embeddings становятся не магией, а управляемым поисковым слоем.

Что изучать дальше

После embeddings стоит разобраться в смежных понятиях:

  1. vector database;
  2. semantic search;
  3. hybrid search;
  4. reranker;
  5. chunking;
  6. metadata filtering;
  7. RAG evals;
  8. groundedness;
  9. query rewriting;
  10. agentic retrieval.

Эти темы помогут строить не просто чат с документами, а надежный AI-поиск.

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

Embeddings - это то же самое, что токены?

Нет. Токены - это фрагменты текста, с которыми работает модель. Embeddings - это числовые векторы, которые представляют смысл текста или объекта для поиска, сравнения и группировки.

Можно ли сделать RAG без embeddings?

Да, можно использовать keyword search или вручную передавать документы. Но embeddings полезны, когда нужно искать по смыслу и находить похожие формулировки без точного совпадения слов.

Embeddings хранят исходный текст?

Обычно embedding - это вектор, а исходный текст хранится рядом отдельно. Но embedding все равно связан с исходными данными, поэтому его тоже нужно защищать и удалять вместе с документом при необходимости.

Почему semantic search иногда находит не то?

Потому что смысловая близость не равна точному совпадению. Запрос может быть коротким, chunk - шумным, модель - слабой для языка, а база - устаревшей. Для точных терминов часто нужен hybrid search.

Как понять, хорошая ли embedding-модель?

Проверьте ее на своих документах и реальных вопросах. Важно, чтобы правильный chunk попадал в top 3, top 5 или top 10, а вопросы без ответа не находили случайный похожий мусор.

Дальше по теме

Похожие материалы