HomeKitchen
New member
Когда мы решили внедрить AI-ассистента в поддержку нашего B2B-продукта, у меня было больше скепсиса, чем веры. B2B — это не чат с котёнком: цена ошибки высока, клиенты задают сложные вопросы, а ответы часто зависят от тарифа, интеграций и версии API. Но нагрузка на первую линию росла, и мы хотели дать людям инструмент, который снимает рутину, а не создаёт новую. Так начался наш путь через RAG, метрики и борьбу с галлюцинациями.
Архитектуру мы собирали вокруг retrieval-augmented generation. В базу знаний попали статьи help center, документация API, release notes, внутренняя wiki, регламенты поддержки и обезличенные фрагменты закрытых тикетов. Важным оказалось не просто загрузить тексты, а правильно нарезать их на чанки, сохранить метаданные — продукт, версия, тариф, язык, дата обновления. Поиск сделали гибридным: BM25 плюс векторные эмбеддинги, затем reranker. Дальше модель получает вопрос, отобранные фрагменты и отвечает только на их основе, обязательно со ссылками на источники. Если релевантность ниже порога, ассистент не фантазирует, а предлагает создать тикет или позвать оператора.
Оценка качества стала отдельным проектом. Мы собрали золотой набор из реальных обращений, размеченный поддержкой, и считали не только CSAT. Смотрели recall@k на этапе поиска, faithfulness ответа, полноту, корректность ссылок, процент эскалаций и время до решения. LLM-as-judge использовали осторожно: сначала калибровали на людях, потом применяли для массовых прогонов. В продакшене запустили A/B-тест: одна группа клиентов общалась с ассистентом, другая — с обычной поддержкой. Отдельно резали метрики по языкам, тарифам и продуктовым модулям, иначе средняя цифра скрывала провалы в узких сегментах.
Контроль галлюцинаций — это не одна кнопка, а набор барьеров. Первый — grounding: модель не должна отвечать без опоры на найденный контекст. Второй — постпроверка: отдельный валидатор сверяет утверждения в ответе с чанками и режет неподтверждённые фразы. Третий — пороги уверенности и обязательный fallback на человека. Четвёртый — аудит: мы логируем вопрос, выдачу поиска, промпт, ответ и оценку, чтобы разбирать инциденты. Ещё добавили кнопку «ответ не помог» и еженедельный разбор худших кейсов. Именно эта дисциплина дала больше эффекта, чем смена модели.
Главный урок: RAG не спасает от плохих данных. Если в wiki устаревшая инструкция, а в тикетах противоречивые решения, ассистент будет уверенно транслировать хаос. Поэтому мы назначили владельцев знаний, ввели свежесть и версионность, чистили дубли и запретили тащить в индекс всё подряд. В B2B особенно важны права доступа: один клиент не должен видеть фрагменты базы другого. Плюс PII, безопасность и изоляция тенантов — это не опция, а обязательная часть архитектуры.
Читателям, которые только заходят в эту тему, советую начать с узкого сценария: например, ответы на вопросы по биллингу или типовые ошибки интеграции. До запуска соберите baseline, создайте eval-набор и договоритесь, что считаете успехом. Не пытайтесь сразу заменить всю поддержку. Оставьте human-in-the-loop, цитаты, кнопку эскалации и понятное объяснение, что ассистент может ошибаться. Обучайте операторов работать с подсказками ассистента, а не конкурировать с ним. И смотрите на метрики не раз в квартал, а регулярно, иначе галлюцинации найдут вас сами.
В итоге я стал относиться к AI-ассистенту как к стажёру: он быстрый, неутомимый и полезный, но без наставника и проверки может наделать дел. У нас получилось снизить рутину, ускорить первые ответы и высвободить время Support-инженеров для сложных кейсов. Это точно не серебряная пуля, но при нормальной архитектуре RAG, честной оценке и контроле галлюцинаций — вполне рабочий инструмент. А какой метрикой вы измеряете качество RAG в поддержке, и какой самый забавный или страшный случай галлюцинации вы ловили?
Архитектуру мы собирали вокруг retrieval-augmented generation. В базу знаний попали статьи help center, документация API, release notes, внутренняя wiki, регламенты поддержки и обезличенные фрагменты закрытых тикетов. Важным оказалось не просто загрузить тексты, а правильно нарезать их на чанки, сохранить метаданные — продукт, версия, тариф, язык, дата обновления. Поиск сделали гибридным: BM25 плюс векторные эмбеддинги, затем reranker. Дальше модель получает вопрос, отобранные фрагменты и отвечает только на их основе, обязательно со ссылками на источники. Если релевантность ниже порога, ассистент не фантазирует, а предлагает создать тикет или позвать оператора.
Оценка качества стала отдельным проектом. Мы собрали золотой набор из реальных обращений, размеченный поддержкой, и считали не только CSAT. Смотрели recall@k на этапе поиска, faithfulness ответа, полноту, корректность ссылок, процент эскалаций и время до решения. LLM-as-judge использовали осторожно: сначала калибровали на людях, потом применяли для массовых прогонов. В продакшене запустили A/B-тест: одна группа клиентов общалась с ассистентом, другая — с обычной поддержкой. Отдельно резали метрики по языкам, тарифам и продуктовым модулям, иначе средняя цифра скрывала провалы в узких сегментах.
Контроль галлюцинаций — это не одна кнопка, а набор барьеров. Первый — grounding: модель не должна отвечать без опоры на найденный контекст. Второй — постпроверка: отдельный валидатор сверяет утверждения в ответе с чанками и режет неподтверждённые фразы. Третий — пороги уверенности и обязательный fallback на человека. Четвёртый — аудит: мы логируем вопрос, выдачу поиска, промпт, ответ и оценку, чтобы разбирать инциденты. Ещё добавили кнопку «ответ не помог» и еженедельный разбор худших кейсов. Именно эта дисциплина дала больше эффекта, чем смена модели.
Главный урок: RAG не спасает от плохих данных. Если в wiki устаревшая инструкция, а в тикетах противоречивые решения, ассистент будет уверенно транслировать хаос. Поэтому мы назначили владельцев знаний, ввели свежесть и версионность, чистили дубли и запретили тащить в индекс всё подряд. В B2B особенно важны права доступа: один клиент не должен видеть фрагменты базы другого. Плюс PII, безопасность и изоляция тенантов — это не опция, а обязательная часть архитектуры.
Читателям, которые только заходят в эту тему, советую начать с узкого сценария: например, ответы на вопросы по биллингу или типовые ошибки интеграции. До запуска соберите baseline, создайте eval-набор и договоритесь, что считаете успехом. Не пытайтесь сразу заменить всю поддержку. Оставьте human-in-the-loop, цитаты, кнопку эскалации и понятное объяснение, что ассистент может ошибаться. Обучайте операторов работать с подсказками ассистента, а не конкурировать с ним. И смотрите на метрики не раз в квартал, а регулярно, иначе галлюцинации найдут вас сами.
В итоге я стал относиться к AI-ассистенту как к стажёру: он быстрый, неутомимый и полезный, но без наставника и проверки может наделать дел. У нас получилось снизить рутину, ускорить первые ответы и высвободить время Support-инженеров для сложных кейсов. Это точно не серебряная пуля, но при нормальной архитектуре RAG, честной оценке и контроле галлюцинаций — вполне рабочий инструмент. А какой метрикой вы измеряете качество RAG в поддержке, и какой самый забавный или страшный случай галлюцинации вы ловили?