Embeddings в RAG: что они делают и чего не гарантируют

Embeddings — это числовые представления, которые помещают текст в общее vector space. В RAG-системе они помогают retrieval-компоненту найти source passages, смысл которых предположительно близок к вопросу. Это полезно, но это не понимание, проверка, permission или истина.

Здесь разобран один узкий вопрос: что embeddings делают внутри RAG pipeline и где заканчивается их ответственность. Это не замена широкого гайда по RAG-системам, где обсуждаются архитектура, scope внедрения и стартовая задача. В центре этой статьи — именно retrieval signal.

1. Определение без маркетинга: embedding — это сигнал близости

Embedding model превращает input — например paragraph, product title или вопрос — в массив чисел фиксированной длины. Inputs, которые модель считает семантически связанными, часто оказываются ближе друг к другу, чем несвязанные. Vector database или search index может сравнить vector вопроса с сохранёнными vectors и вернуть ближайшие candidates.

Ключевое слово — candidate. Высокий similarity score не доказывает, что passage отвечает на вопрос. Он не доказывает, что passage актуален, разрешён конкретному пользователю, полон, authoritative или не содержит противоречащего exception. Он означает только, что encoder посчитал два input связанными в своём learned representation.

Например, сотрудник спрашивает: «Когда можно вернуть оплату за подписку?» Query embedding может найти passage с заголовком «Отмена и возвраты». Это хороший старт. Но для ответа нужны правильные product, country, дата вступления policy, customer status и exceptions. Если условия находятся в другом месте, один vector match не может безопасно заполнить пропуски.

Поэтому embedding находится в retrieval layer между подготовкой source и составлением ответа. Это не database schema, не access control, не policy engine и не decision maker.

2. Как embeddings работают в RAG pipeline

EMBED-5 — компактная схема handoffs, которые делают сигнал полезным:

1. RECEIVE — принять owned source passage с ID, version, access rule, language, lifecycle и source locator.
2. ENCODE — построить vector named embedding model и сохранить model version рядом с ним.
3. RETRIEVE — найти query-near candidates, затем применить deterministic filters для tenant, role, language, document type и current lifecycle.
4. VERIFY — проверить, поддерживает ли выбранное evidence нужное утверждение, содержит ли material limits и нет ли неразрешённого contradiction.
5. ROUTE — перейти к ответу с citation, human review либо явному no-answer.

Для documents и queries в одном index обычно используют один encoder. Замена model, normalization, chunking policy или правил language handling — не косметическая правка: она меняет, какие passages становятся «близкими». Эти решения нужно versionировать и проверять на representative evaluation set до смены active index.

type RetrievalCandidate = {
  sourceId: string;
  sourceVersion: string;
  locator: string;
  text: string;
  embeddingModel: string;
  accessRule: string;
  lifecycle: "current" | "superseded" | "quarantined";
  similarity: number;
};

const candidates = search(queryVector, { topK: 12 });
const permitted = candidates.filter((item) =>
  caller.permitted(item.accessRule) && item.lifecycle === "current",
);

Код намеренно не превращает similarity в ответ. Answer layer ещё должен решить, поддерживает ли полученный материал вопрос, и показать citation, который может проверить reviewer.

3. Сквозной пример: policy retrieval для support assistant

Представим небольшой support corpus с тремя documents: public refund policy, country-specific exception и internal escalation procedure. Ingestion сохраняет с каждым passage title, effective date, customer segment, access rule и heading locator. Каждый passage получает embedding после chunking, а не до него.

Когда customer спрашивает о refund, query embedding может поднять general policy и exception. Filters удаляют internal escalation notes до того, как их увидит модель. Затем система проверяет, относятся ли оба passages к plan и country клиента. Если exception неоднозначен или policy уже не current, нельзя выводить outcome из близкого vector match. Правильный маршрут — bounded response вроде «По доступной policy нельзя подтвердить eligibility» и передача case в authorised support path.

Здесь embeddings помогают: они сужают поиск до plausible evidence. Они не заменяют условия policy и не дают право раскрыть document. Такое же разделение нужно для contracts, HR guidance, product manuals и multilingual internal knowledge bases.

4. Где embeddings помогают, а где нужен более простой механизм

Embeddings подходят, когда люди задают разнообразные natural-language questions к bounded, governed набору text, а exact keyword search пропустит нужные формулировки. Они полезны также для clustering схожих support issues, рекомендаций related documentation и подачи candidate passages в hybrid search.

Это часто не первый инструмент, если операция имеет deterministic key. Нужен balance order A-1042 — запросите system of record. Нужна обязательная форма — используйте validation. Outcome зависит от маленькой decision table — смоделируйте table. Source без owner, устаревший или недоступный не исправит новая embedding model.

Именно это разделение предотвращает типичный failure: команда тратит время на tuning vector similarity, хотя corpus содержит duplicated policies, нет dates, слабые access rules или отсутствует способ показать source. Материал о качестве источников для RAG описывает upstream ответственность, а chunking для RAG — почему граница passage меняет то, что представляет embedding.

5. Ограничения, которые нужно проверить до доверия retrieval

Смысл сжат. Vector не сохраняет каждую деталь source. Negation, date, product code, number или узкий exception могут быть критичны, но слабо отражены в широком semantic representation. Держите structured fields и deterministic filters рядом с vector search.

Similarity относителен. Не существует универсального «безопасного» threshold. Его смысл зависит от model, language, corpus, chunking policy и competing candidates. Проверяйте distribution scores на своих questions, а не переносите threshold из чужого проекта.

Retrieval может уверенно ошибаться. Близкие passages могут описывать retired product, другого tenant, связанную, но несовместимую procedure или противоречащий exception. Lifecycle, permissions, metadata filters и source citations должны работать до доверия к response.

Language coverage различается. Если multilingual RAG включает Armenian, Russian и English, retrieval нужно тестировать отдельно по каждому языку. Translation, transliteration и mixed-language queries меняют vector neighbourhoods. Один хороший English demo не доказывает такую же работу в других языках.

Embedding не судит о достаточности. Вопрос может найти что-то связанное, но не получить достаточно evidence для ответа. Явное no-answer behavior — требование к продукту, а не недостаток, который нужно скрыть.

Минимальная acceptance-проверка

Начните с небольшого evaluation set, а не полного re-index. Включите обычные вопросы, paraphrases, exact identifiers, вопросы о stale policy, denied-access, mixed-language inputs при необходимости и вопросы, которые должны получить no-answer. Для каждого результата проверьте returned passage, source version, access decision, locator и то, подтверждает ли evidence заявленный ответ.

require(source.id && source.version && source.accessRule);
require(vector.modelVersion && candidate.provenance);
require(filters.applied && candidate.lifecycle === "current");

answerable = evidence.supportsClaim && !evidence.conflicts;
route = answerable ? "answer-with-citation" : "no-answer-or-review";

Практический результат — не абстрактно «лучшие embeddings». Это retrieval layer, который может показать, почему был выбран passage, разрешён ли он, из какой version он пришёл и когда система обязана отказаться от ответа. Для архитектурного review или bounded RAG pilot используйте гайд по RAG-системам и кейсы.