RAG для отдела продаж: ассистент по продуктам, кейсам и возражениям

RAG-ассистент для продаж полезен, когда помогает менеджеру найти актуальную утверждённую информацию о продукте, релевантный кейс и допустимый ответ на возражение. Это не система для импровизации обещаний, изменения цены или автономной отправки сообщений. Надёжный результат — предложение с источниками, которое человек может проверить, исправить и использовать.

В статье описан SALES-RAG-8 — ограниченный source-to-answer контракт для вопросов о продукте, поиска кейсов и подготовки к возражениям. За широкой архитектурой retrieval-системы переходите к услуге RAG-систем, а за evidence и границами delivery — к кейсам.

Начните с решения продавца, а не с модели

Первый вопрос — не «какую векторную базу выбрать?», а «какое решение станет проще и что останется за менеджером?». Реалистичный первый scope — черновик ответа для конкретного аккаунта и продукта, со ссылками на источники и явным маршрутом no-answer.

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

SALES-RAG-8: workflow

Контракт состоит из восьми этапов:

1. Receive — принять запрос с account, product, locale, стадией сделки и разрешённым CRM-контекстом.
2. Classify — отделить product lookup, поиск proof, подготовку к возражению, коммерческий вопрос и escalation.
3. Filter — отфильтровать реестр источников по продукту, версии, рынку, аудитории, статусу approval и правам доступа.
4. Retrieve — вернуть фрагменты с source ID, revision, owner и стабильным locator.
5. Compose — собрать короткое предложение, отдельно показав evidence, uncertainty и вопросы владельцу.
6. Verify — проверить каждый существенный claim, запрещённые claims, lifecycle источника и ссылку-цитату.
7. Review — направить commercial, legal, security или account-specific утверждения авторизованному владельцу.
8. Record — сохранить одобренный ответ либо outcome escalation, не отправляя его клиенту автоматически.

request(account, product, locale, deal_stage)
  -> permitted_context
  -> approved_source_filter
  -> cited_retrieval
  -> bounded_draft
  -> claim_and_policy_gate
  -> reviewer_or_escalation
  -> CRM evidence receipt

В финальном receipt сохраняются использованные источники, reviewer для исключения и неразрешённые вопросы. Текст модели не становится источником истины.

Реестр источников до индексации файлов

Материалы для продаж обычно лежат в product pages, презентациях, заметках звонков, security-документах, прайс-листах и кейсах. Если индексировать их без ownership, получится удобный, но ненадёжный поиск. У каждого доступного источника должны быть как минимум:

• source ID, название, owner и дата review;
• продукт, версия, язык, рынок и аудитория;
• статус approval и разрешение на использование в продажах;
• scope доступа и retention boundary;
• revision, период действия и связь с заменяющим документом;
• стабильный URL или document locator.

Именно реестр позволяет исключить старую презентацию после изменения продукта или не показать internal security note в prospect-facing ответе. Версии и удаление источников подробнее разобраны в статье Обновление индекса RAG: ingestion, версии и удаление данных.

Ответ о продукте — это evidence packet

Полезный пакет компактный: вопрос клиента, разрешённый account context, два-пять фрагментов evidence, citations, черновик ответа, uncertainty и route. Ассистент может сказать «утверждённая документация подтверждает X» и дать ссылку. При отсутствии evidence он обязан сказать: «Я не могу подтвердить это по утверждённым источникам».

Пример:

ВХОД
Аккаунт: действующий клиент из ритейла
Вопрос: поддерживает ли продукт базу знаний на русском языке?
Контекст: стадия оценки; scope внедрения ещё не утверждён

ПРЕДЛОЖЕНИЕ
Evidence: DOC-144 rev.12, section 4; CASE-019 rev.3, scope note
Черновик: «В текущей документации описан русский контент как индексируемый
источник. Для ваших документов всё равно нужен multilingual evaluation set
и отдельные acceptance criteria».
Route: owner review до любого commitment по внедрению

Одна документированная возможность не превращается в обещание качества, срока или fit для любого корпуса. Multilingual deployment требует отдельной оценки — почему язык не является checkbox, объясняет статья о multilingual RAG.

Возражение должно стать проверяемым вопросом

Возражение — не сигнал «выиграть сделку». Это запрос: выделить concern, найти разрешённые evidence, назвать пробел и направить следующему owner. Security-вопрос может потребовать security owner, procurement-вопрос — актуальную коммерческую политику, а сравнение функций — validation product manager.

Используйте objection card из четырёх полей:

• Concern: слова покупателя без изменения смысла.
• Evidence: актуальные утверждённые факты с locator.
• Boundary: что evidence не доказывает.
• Next action: named owner, вопрос или разрешённый follow-up.

Формат не даёт ассистенту выдавать сравнение с конкурентом, гарантию или договорное утверждение, которого нет в материалах.

CRM — контекст, а не доказательство

CRM может передать identity аккаунта, сегмент, стадию, owner и одобренные прошлые действия. Но CRM не должна молча расширять круг данных или обещаний. Оставьте отдельными три контракта:

1. Identity contract: server-trusted account, роль пользователя и tenant boundary.
2. Knowledge contract: eligibility источника, revision и citations.
3. CRM contract: черновик или reviewed evidence receipt, а не автономное внешнее действие.

Для email workflow с human approval и delivery read-back см. AI-ассистент для sales email: персонализация без массового спама. Он намеренно отделён от retrieval.

Acceptance checks перед пилотом

Проверьте небольшой репрезентативный test set, а не публикуйте общий процент точности. Включите known-answer и no-answer вопросы, устаревшие документы, denied sources, смешанные языки, wrong-account context и возражения, которые требуют escalation.

Размечайте failure по типу: неверный, устаревший или отсутствующий источник; неправильные права; неподтверждённый claim или неверный route. Тогда исправление становится конкретным: обновить metadata, убрать источник, изменить policy gate или добавить case в evaluation.

Каким бывает контролируемый первый пилот

Выберите одну product line, одну sales-команду и ограниченный набор approved documents. Начните с подготовки черновика внутри seller workspace. Не подключайте автоматическую отправку email, расчёт цены или изменение CRM stage, пока source, policy и review evidence не устойчивы.

Артефакты пилота вполне инженерные: source registry, access map, retrieval contract, test set, reviewer matrix, failure log, monitoring signals и rollback path. Цель — не «AI закроет больше сделок», а проверяемый evidence workflow, который показывает, где он помогает и где обязан остановиться.

Если нужно разобрать один sales-процесс и выбрать такой controlled pilot, подготовьте бриф или посмотрите RAG-системы.