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

Ассистент для поддержки полезен только тогда, когда сотрудник может проверить, почему он дал ответ. Гладкий текст без актуальной ссылки на документацию создаёт вторую проблему: клиент получил формулировку, но команда не понимает, утверждена ли она, актуальна ли и относится ли к ситуации.

Здесь разбирается узкий вопрос внедрения: как построить RAG для поддержки так, чтобы в ответе были проверяемые ссылки на документацию. Материал дополняет страницу RAG-систем и контролируемый AI engineering brief, а не заменяет решение сотрудника поддержки или владельца политики.

Начните с решения поддержки, а не с окна чата

Выберите одну ограниченную задачу: объяснить документированный шаг настройки, найти актуальное правило биллинга или процедуру устранения известной ошибки. Сразу зафиксируйте, что ассистент не решает: исключения для конкретного аккаунта, возвраты вне опубликованного правила, юридические и security-обещания, недокументированное поведение продукта. Для них нужен именованный human route.

Ссылка ценна, только если она указывает на источник, который реально использовался. Минимальный evidence record: source ID, revision, section locator, URL, state документа и scope доступа. Эти поля хранятся рядом с chunk, а не восстанавливаются моделью из похожего текста.

Подготовьте документацию как evidence

В поддержке обычно смешаны product guides, release notes, runbooks, macros и internal escalation notes. Каждый источник сначала регистрируют.

Не индексируйте документ только потому, что его легко выгрузить. Черновик без owner, устаревший FAQ или private escalation note без access contract должны попасть в review queue. При chunking сохраняйте связь между текстом, заголовком и ссылкой: короткая похожая фраза без понятного locator не годится для проверяемой поддержки.

Спроектируйте workflow SUPPORT-LINK-8

Этот авторский паттерн делает связь ответа с источником явной.

1. Receive. Принять вопрос с channel, product, language и trusted context агента или клиента.
2. Classify. Определить: поиск по документации, account action, escalation или unsupported request.
3. Filter. Ограничить candidates по product, locale, audience, state и effective date до ranking.
4. Retrieve. Выбрать разные актуальные passages вместе с source ID, revision и locator.
5. Compose. Сформировать короткий ответ только из разрешённого evidence и приложить human-openable links.
6. Verify. Проверить, что каждое material claim имеет актуальный locator и revision.
7. Route. Направить недостаточное evidence, conflict, account action или consequential request именованному owner.
8. Record. Сохранить минимальный answer receipt: request class, source IDs, revisions, links, route и feedback.

Граница между retrieve и compose принципиальна. Retrieval выбирает допустимое evidence, но не разрешает придумать недостающий шаг. Если найденного материала недостаточно для короткого ответа с рабочей ссылкой, правильный результат — no-answer или escalation.

Пример input и проверяемого output

Агент спрашивает: «Можно ли изменить billing contact после выпуска invoice?» Система получает product code и роль агента, фильтрует approved billing documentation для этого продукта, находит процедуру и проверяет anchor.

INPUT
question: change billing contact after invoice
scope: support-agent / product-a / en

OUTPUT
answer: Документированный путь — отправить изменение billing contact до следующего invoice cycle.
evidence: Billing contacts — revision 24 — section "After an invoice"
link: https://docs.example.com/billing-contacts#after-an-invoice
boundary: Для уже выпущенных invoices нужен billing operations queue.
route: support-answer / billing-operations

Ответ не обещает действие для конкретного аккаунта. Он отделяет общее документированное правило от следующего owner для исключения. Если два approved документа противоречат друг другу, агент видит conflict и route, а не искусственный выбор по похожести формулировки.

Считайте интеграции контрактами

Документационная система должна отдавать stable IDs, revisions, lifecycle events, audience labels и открываемые canonical URLs. Интеграция с helpdesk должна разделять retrieval-only помощь и write action: изменение тикета, кредита или аккаунта. Для write action нужны отдельные authorization, idempotency и read-back; ссылка на статью не является правом менять данные.

Identity boundary не менее важна. Actor, tenant и role определяются на сервере; access label из сообщения нельзя считать trusted. Если документация многоязычна, в receipt сохраняются язык и версия источника. Переведённое объяснение не должно молча ссылаться на другое правило.

Для обновлений и удаления используйте source event и reconciliation. Сначала revised или revoked source исключается из retrieval; потом пересобираются или удаляются derived chunks; затем probes подтверждают отсутствие или currentness. Так старый macro не останется доступным только потому, что вчера успешно завершился embedding job.

Проверьте пилот до зависимости агентов от него

Acceptance criteria должны тестировать решения, а не только стиль текста.

• Permitted агент получает актуальный ответ и кликабельный source locator.
• Каждое material statement сопоставляется с source ID, revision и locator в answer receipt.
• Retired документ и его chunks исключаются после lifecycle change.
• Пользователь вне scope не получает источник через paraphrase, другой язык или цитату из тикета.
• Вопрос без достаточного evidence даёт ясный no-answer или escalation route.
• Конфликтующие current sources показывают оба locator и доходят до owner.
• Broken и redirected links выявляются до доставки ответа.
• Account actions не входят в retrieval flow, пока не проходит их отдельный authorization contract.

Начните с небольшой curated evaluation set: known answers, no-answer questions, stale revisions, denied scopes, conflicts и link failures. Не заявляйте общий процент accuracy, если нет определённых sample, method и threshold. Набор проверяемых failure cases даёт support owner конкретный предмет для approval.

Эксплуатируйте ответы со ссылками на документацию

Наблюдайте source-to-index lag, citation-link failures, no-answer rate, conflict routes, access denials, feedback corrections и handoffs, которые указали на missing source. No-answer может быть здоровой границей; всплеск после release способен показать проблему документации или ingestion. Неисправная ссылка означает, что ответ нельзя проверить даже при правильной формулировке.

Для классов источников нужен свой review rhythm. Release notes могут требовать быстрой promotion, policy pages — owner approval, temporary incident notes — срока истечения. Answer receipt должен быть небольшим и access-controlled: он помогает проверить ответ, но не становится неконтролируемой копией customer или internal content.

Начните с одного product area, одного семейства документов и одной очереди поддержки. Прогоните evaluation set, соберите feedback агентов, исправьте source register и только потом расширяйте scope. Чтобы обсудить контролируемый пилот для конкретного workflow, откройте RAG-системы или начните AI engineering brief.