Автоматизация клиентского сервиса в медицине — это всегда баланс между точностью данных и скоростью ответа. Рассказываем, как мы создавали для фармацевтической компании «Буарон» умного помощника на базе Yandex Cloud Agent, который обеспечивает круглосуточную обработку запросов и использует связку PHP и WordPress.
Есть два фактора, которые гарантированно дают большую нагрузку на службу поддержки портала – это сложный продукт и широкий ассортимент. Фармацевтическая компания «Буарон» объединила оба. «Буарон» (Boiron) – один из мировых лидеров в производстве лекарств на основе природных субстанций, который в России представляет 130 гомеопатических монопрепаратов и 10 комплексных лекарств. База знаний включает в себя не только описания отдельных средств, но и комплексные решения, такие как «ЛОР-протокол», что требует от ИИ-ассистента высокой точности при сопоставлении запроса пользователя с нужным разделом.
Портал компании заключает в себе огромный объем информации, в которой посетителю непросто ориентироваться. В год пользователи оставляют на сайте более 300 000 запросов – это больше 800 в сутки, при этом ответы не всегда находились, а часть обращений терялась или требовала личного участия специалистов.
Перед нами в QSOFT стояла задача автоматизировать обработку пользовательских запросов на сайте о клинической гомеопатии, снизить нагрузку на специалистов и сократить число пропущенных обращений. Для этого было решено создать умного помощника на базе Yandex Cloud Agent.
Почему мы отказались от OpenAI в пользу YandexGPT
Для медицинского проекта в РФ выбор стека был продиктован тремя критичными факторами. Во-первых, это закон 152-ФЗ. Мы работаем с данными (иногда медицинскими), сервера должны находиться в России. Во-вторых, финансовый вопрос. Клиенту важно платить в рублях по счету, а не искать способы оплаты зарубежных сервисов. В-третьих, локализация. YandexGPT Pro — одна из лучших моделей, понимающих специфику русского языка и медицинского контекста.
Мы выбрали Yandex Cloud Agent Atelier. Это решение «RAG из коробки» (Retrieval-Augmented Generation). Казалось бы, достаточно загрузить файлы и нажать кнопку. Но на практике мы столкнулись с нюансами, которые пришлось обходить инженерными методами.
Архитектура монолита на PHP против микросервисов
Мы отказались от Python и FastAPI в пользу привычного стека. У нас был WordPress, где сосредоточена вся бизнес-логика, и PHP 8 прекрасно справлялся с ролью прокси для API.
Многие скажут: «Зачем PHP? Надо было брать Python + LangChain», но встраивать Python-микросервис в монолитный проект ради одного эндпоинта — это оверхед (devops, деплой, поддержка). PHP 8+ быстро работает через cURL, обработка JSON элементарна, а весь бэкенд уместился в 5–6 легких классов без внешних зависимостей.
Схема взаимодействия выглядит так:
-
Frontend на ванильном JS. Мы не стали использовать React, чтобы не грузить проект лишним легаси. Для отображения ответов взяли библиотеку marked.js, так как Markdown — это «родной» язык модели. Обязательно нужно делать поддержку рендеринга MD в интерфейсе, иначе вместо красивого текста пользователь увидит мешанину из звездочек и решеток.
-
Backend в виде плагина для WP. Класс-обертка YandexAssistants.php проксирует запросы, считает токены и хранит логи.
-
Yandex Cloud с настроенным промптом. Агент с подключенной базой знаний через Search Index.
-
Интеграция с CRM-системой заказчика. Бот позволяет оставить контактные данные для обратной связи с менеджером, если вопрос выходит за рамки автоматического сценария.
Пять главных нюансов YandexGPT, о которых молчит реклама
1. RAG это инструмент, а не автоматика
В экосистеме Яндекса поиск по файлам — это FileSearchTool. Модель сама решает, обращаться ли к нему. В медицине это фатально. Бот может выдумать дозировку из «общих знаний», проигнорировав ваши протоколы.
В мировой практике архитектура LLM + RAG показала себя стабильнее и дешевле, чем попытки «дообучить» модель (Fine-tuning). Точность здесь достигает ~90%: если информация есть в текстовых файлах базы знаний, бот её находит и перефразирует корректно.
Однако важно понимать: LLM не детерминирован. Чтобы минимизировать риск «галлюцинаций», мы использовали «метод кнута» в системном промпте, прописав капсом: «Ты ОБЯЗАН использовать инструмент поиска FileSearchTool. Вся медицинская информация находится там. ОБРАЩАЙСЯ в поиск ВСЕГДА».
Это позволило боту строго придерживаться базы и не давать опасных медицинских назначений. Если пользователь спрашивает схему лечения, бот либо цитирует официальную инструкцию (если нашел), либо отправляет к врачу. Это вопрос безопасности, а не технологии. Но есть и проблема «слепых зон»: если пользователь спрашивает про симптом, который забыли описать в базе, бот бессилен. Это лечится только постоянным дополнением текстовых файлов.
2. Проблема фиксированного чанкинга и мусора на входе
Яндекс нарезает файлы на куски по 500–600 токенов с перекрытием, и вы не можете на это влиять. В итоге важный протокол может быть разрезан посередине. Поиск найдет первую часть, а противопоказания из второй выпадут из контекста. Кроме того, бот иногда начинал цитировать меню сайта или политику конфиденциальности.
Наше решение. Мы написали препроцессор export_rag_split.php, который вычищает HTML-теги и атрибуты. Затем мы прогнали тексты через Gemini, чтобы он переформатировал статьи, повторяя ключевые слова и лучше попадал в «окна» чанков.
3. Умные сценарии и работа с контекстом через Linked List
Структура знаний бота построена на более чем 20 ключевых темах общения (интентах), которые теперь интегрированы непосредственно в RAG-базу. Мы выделили самые частые запросы (поиск по симптомам, информация о препаратах, поиск ближайших центров) и на их основе сформировали более 100 вариантов ответов, которые модель извлекает из контекста знаний.
Поскольку Яндекс работает через механизм «Linked List» (связанные списки ответов), реализация которого отличается от общепринятого стандарта с единым ID всего диалога, нам пришлось реализовать сохранение previous_response_id. Это необходимо прежде всего для сохранения контекста диалога между запросами и позволяет продолжать беседу, не теряя нить разговора даже при обновлении страницы.
4. Агрессивные контент-фильтры как черный ящик
Эту проблему мы поймали только на проде. Внезапно на безобидные вопросы о лекарствах бот начал отвечать стандартной заглушкой: «Я не могу ответить на этот вопрос». В ответе API значилось reason: content_filter, после чего дальнейшее продолжение диалога становилось невозможным.
Мы гадали, на что именно срабатывает триггер: слово «лекарство»? Слово «доза»? В итоге выяснилось, что фильтр настроен очень агрессивно на любые темы, которые могут показаться «опасными советами». Чтобы минимизировать срабатывания, пришлось очень аккуратно формулировать промпт, позиционируя бота не как врача, а исключительно как «справочник».
Но возникла другая проблема — в официальной документации Яндекса не было информации, что делать в случае блокировки. Решение нашлось только в «Yandex AI Studio SDK» на английском языке (больше это нигде не упоминалось). Оказалось, что нужно взять previous_response_id предыдущего сообщения и повторить запрос. Однако даже этот метод иногда приводил к повторному срабатыванию фильтра, поэтому в итоге было решено просто создавать новый диалог при получении такой ошибки.
5. Лень при вызове внешних функций
Одной из задач был поиск ближайших гомеопатических центров через API. Бот неохотно вызывал функцию find_homeopathic_centers, предпочитая отвечать общими фразами. Пришлось снова использовать промпт-инженерию и жестко прописать сценарии. Если юзер спрашивает «где купить» — бот обязан использовать инструмент find_homeopathic_centers.
Бизнес-результаты и экономика независимости
Внедрение бота позволило не только повысить лояльность клиентов, но и дало конкретные результаты.
Почему это выгодно
-
70% заявок теперь обрабатываются автоматически, без привлечения менеджера.
-
В 2 раза снизилось общее количество необработанных вопросов.
-
Ежемесячно система успешно закрывает 500+ глубоких обращений.
Почему это выгодно заказчику
Мы отказались от дорогих SaaS-платформ (экономия от 5000 руб/мес за лицензию). Оплата идет напрямую Яндексу строго за использованные токены, что при текущей нагрузке обходится всего в пару тысяч рублей в месяц. При этом мы внедрили механизм ограничения запросов ChatRateLimiter на стороне PHP. В качестве хранилища данных для лимитера используется MySQL (таблица chat_rate_limits), что позволяет эффективно отсекать аномальную нагрузку и защищать бюджет, блокируя IP после 5 запросов в минуту.
Ретроспектива и планы на будущее
Сегодня наш ассистент выдает корректные ответы в 85–90% случаев. Однако мы видим зоны роста.
-
Стриминг ответов через SSE. Сейчас генерация занимает 2–6 секунд. Мы сгладили это анимацией «typing dots», но правильнее использовать потоковую выдачу, чтобы текст появлялся по буквам.
-
Автоматизация базы знаний. Обновление базы пока ручное. Стоит внедрить Management API для авто-синхронизации по Cron.
-
Умный Rate Limiter. Бан по IP — это риск для офисов за одним роутером. В будущем добавим Fingerprinting браузера.
Финальная мысль
Сделать RAG-бота на WordPress в 2026 году — задача реальная. Вам не нужны Python-разработчики, но нужно быть готовым чистить данные, бороться с фильтрами и буквально заставлять модель работать через промпты.
Автор: qsoft
