Автоматизация клиентского сервиса в медицине требует баланса между точностью и скоростью. Рассказываем, как для фармацевтической компании «Буарон» был разработан ИИ-помощник на базе Yandex Cloud Agent с использованием PHP и WordPress.

«Буарон» — мировой лидер в производстве гомеопатических препаратов, который в России представляет 130 монопрепаратов и 10 комплексных лекарств. На сайте компании ежегодно поступает более 300 000 запросов, что создаёт высокую нагрузку на поддержку. Пользователи часто не могут найти нужную информацию, а часть обращений теряется или требует ручной обработки.

Целью проекта стало автоматизировать обработку запросов, снизить нагрузку на специалистов и минимизировать пропущенные обращения. Для этого была выбрана платформа Yandex Cloud Agent — решение с поддержкой RAG (Retrieval-Augmented Generation) «из коробки».

Почему YandexGPT, а не OpenAI

Выбор YandexGPT обусловлен тремя ключевыми факторами. Во-первых, соблюдение закона 152-ФЗ: все данные, включая медицинские, должны храниться на серверах в России. Во-вторых, финансовая прозрачность — оплата в рублях по российскому счёту. В-третьих, высокая локализация: YandexGPT Pro лучше понимает русский язык и медицинский контекст.

Архитектура: PHP и WordPress вместо Python

Вместо Python и микросервисов была выбрана привычная стековая связка — WordPress и PHP 8. Встраивать отдельный Python-сервис ради одного эндпоинта было бы избыточно с точки зрения DevOps и поддержки.

Решение построено по следующей схеме:

• Frontend — ванильный JavaScript. Для отображения ответов используется библиотека marked.js, так как модель генерирует ответы в формате Markdown. Это позволяет корректно рендерить списки, заголовки и выделения.
• Backend — плагин для WordPress. Класс YandexAssistants.php выступает прокси для API, считает токены и ведёт логи.
• Yandex Cloud — агент с подключённой базой знаний через Search Index.
• CRM-интеграция — при необходимости бот предлагает оставить контактные данные для связи с менеджером.

Пять ключевых нюансов YandexGPT

1. RAG — это не автомат, а инструмент
Yandex использует FileSearchTool, но модель решает, использовать ли его. В медицине это опасно: бот может «выдумать» дозировку, опираясь на общие знания.

Чтобы избежать галлюцинаций, в системный промпт было добавлено строгое указание: «Ты ОБЯЗАН использовать инструмент поиска. Вся медицинская информация находится там. ОБРАЩАЙСЯ в поиск ВСЕГДА». Это заставило модель строго придерживаться базы знаний.

Если информация отсутствует в базе, бот не отвечает. Это требует постоянного обновления контента, но гарантирует безопасность.

2. Проблема чанкинга и мусора
Yandex разбивает файлы на чанки по 500–600 токенов без возможности настройки. Важный текст может быть разрезан, а в ответ попасть меню сайта или политика конфиденциальности.

Решение: препроцессор export_rag_split.php очищает HTML, а тексты дополнительно оптимизируются через Gemini — для лучшего попадания в чанки и дублирования ключевых терминов.

3. Контекст диалога через Linked List
Yandex использует механизм связанных списков, а не единый ID диалога. Чтобы сохранять контекст, пришлось вручную сохранять previous_response_id. Это позволяет продолжать беседу даже после перезагрузки страницы.

4. Агрессивные контент-фильтры
На проде бот начал блокировать безобидные вопросы с ответом «Я не могу ответить на этот вопрос» (причина: content_filter). Фильтры срабатывали на любые упоминания лекарств и дозировок.

Решение: позиционирование бота как «справочника», а не источника медицинских рекомендаций. При срабатывании фильтра — создание нового диалога, так как повтор запроса с previous_response_id не всегда помогал.

5. Лень вызывать внешние функции
Бот игнорировал вызов API для поиска гомеопатических центров. Пришлось жёстко прописать в промпте: при запросах «где купить» — обязательно использовать инструмент find_homeopathic_centers.

Бизнес-результаты

Внедрение бота дало ощутимые результаты:

• 70% запросов обрабатываются автоматически.
• Количество необработанных обращений сократилось вдвое.
• Ежемесячно закрывается более 500 глубоких обращений.

Заказчик экономит на лицензиях SaaS-платформ (от 5000 руб/мес). Оплата идёт напрямую Яндексу — по факту использования токенов. При текущей нагрузке расходы составляют всего несколько тысяч рублей в месяц.

Для защиты бюджета реализован ChatRateLimiter на PHP с хранением данных в MySQL. Система блокирует IP после 5 запросов в минуту, предотвращая аномальную нагрузку.

Планы на будущее

Сейчас точность ответов — 85–90%. Работа ведётся над улучшениями:

1. Стриминг ответов через SSE — чтобы текст появлялся по мере генерации, а не после полной обработки (сейчас 2–6 секунд).
2. Автоматизация обновления базы знаний — через Management API и Cron для синхронизации контента.
3. Умный Rate Limiter — вместо блокировки по IP будет использоваться браузерный fingerprinting, чтобы не блокировать пользователей из одного офиса.

Создать RAG-бота на WordPress в 2026 году реально. Python и оркестраторы не обязательны. Главное — качественная подготовка данных, работа с промптами и готовность решать неочевидные технические проблемы.

Автоматизация клиентского сервиса в медицине — это всегда баланс между точностью данных и скоростью ответа. Рассказываем, как мы создавали для фармацевтической компании «Буарон» умного помощника на базе 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% случаев. Однако мы видим зоны роста.

1. Стриминг ответов через SSE.Сейчас генерация занимает 2–6 секунд. Мы сгладили это анимацией «typing dots», но правильнее использовать потоковую выдачу, чтобы текст появлялся по буквам.
2. Автоматизация базы знаний.Обновление базы пока ручное. Стоит внедрить Management API для авто-синхронизации по Cron.
3. Умный Rate Limiter.Бан по IP — это риск для офисов за одним роутером. В будущем добавим Fingerprinting браузера.

Финальная мысль

Сделать RAG-бота на WordPress в 2026 году — задача реальная. Вам не нужны Python-разработчики, но нужно быть готовым чистить данные, бороться с фильтрами и буквально заставлять модель работать через промпты.