Skip to main content
7 мин чтенияNorvalda

Как построить RAG-агента поддержки: архитектура, затраты и подводные камни

Как на самом деле работает RAG-агент поддержки, во что обходится его эксплуатация и какие провалы тихо подрывают доверие, если пропустить guardrails.

RAG-чатбот — это не модель, которая «знает ваш бизнес». Это система поиска, пристыкованная к языковой модели: когда клиент о чём-то спрашивает, система сначала находит самые релевантные фрагменты вашей документации, а затем просит LLM ответить, опираясь только на них. Сделайте поиск хорошо — и модель остаётся фактологичной. Сделайте плохо — и вы получаете уверенного лжеца под вашим брендом.

Архитектура целиком

  • Источники знаний: статьи справочного центра, продуктовая документация, прошлые тикеты, политики. Чистые, без дублей, с понятным ответственным за обновления.
  • Чанкинг и эмбеддинги: документы режутся на фрагменты и превращаются в векторы, чтобы искать по смыслу, а не только по ключевым словам.
  • Vector store: база (pgvector, Pinecone, Qdrant), которая за миллисекунды возвращает ближайшие фрагменты к любому вопросу.
  • Retrieval + промпт: топовые фрагменты вставляются в промпт с инструкцией отвечать только по ним и ссылаться на источник.
  • Guardrails: правила отказа, порог уверенности и fallback на человека, когда поиск вернул слабый результат.

Во что это реально обходится

Важны две статьи затрат. Стоимость сборки в основном разовая: чистка базы знаний, сборка конвейера, написание guardrails и тюнинг поиска. Стоимость эксплуатации — за разговор: эмбеддинги дёшевы, но каждый ответ оплачивает вызов LLM плюс токены извлечённого контекста. Грамотно очерченный агент обычно закрывает уверенное большинство рутинных тикетов за долю стоимости ответа человека, и экономия растёт по мере улучшения базы. Ошибка — считать его фиксированным активом; это система, которой нужен владелец и бюджет на поддержку.

Провалы, которые топят проекты

  • Галлюцинации без ссылки: если модель может ответить, не показав источник, рано или поздно она его выдумает. Принуждайте отвечать с привязкой к источнику.
  • Устаревшая база знаний: агент уверенно цитирует политику, которую вы поменяли три месяца назад. Обновлениям нужен владелец, а не благие намерения.
  • Нет fallback на человека: когда поиск слабый, вежливое «Соединю вас с сотрудником» всегда лучше неверного ответа.
  • Поиск возвращает не те фрагменты: обычно это проблема чанкинга или эмбеддингов, а не модели — чините до того, как винить LLM.
  • Запуск без оценки: нельзя улучшить то, что не измеряешь. С первого дня отслеживайте долю решённых, долю эскалаций и точность ответов.

Хороший RAG-агент поддержки — это в основном неэффектная работа: чистые данные, честные guardrails и петля измерений. Модель — самая простая часть. Мы строим их так же, как и всё остальное: с сеньорским ревью, под чёткую задачу и с планом на день, когда база знаний изменится.