Багатомовний асистент ШІ: обслуговування клієнтів кількома мовами

Польська компанія e-commerce виходить на чеський, словацький та румунський ринки. Відділ обслуговування клієнтів отримує запити чотирма мовами. Найм носіїв мови для кожної з них — дорого, а переклад запитів через Google Translate перед відповіддю польського агента створює затримки та стилістичні помилки, які клієнти одразу помічають.

Це не проблема, ексклюзивна для e-commerce. Вона стосується будь-якої компанії, яка обслуговує клієнтів з різних країн, наймає багатонаціональну команду або просто має продукти з кількома мовними версіями. Багатомовний асистент ШІ вирішує цю проблему інакше, ніж класичний підхід з окремими ботами для кожної мови.

Інтуїтивний підхід: створити окремого асистента польською, окремого англійською, перекласти всю базу знань на кожну мову. Така система швидко стає операційним кошмаром. Кожне оновлення контенту вимагає оновлення в N мовах, узгодженість відповідей між версіями важко підтримувати, а вартість масштабування зростає лінійно з кількістю мов.

Архітектури на базі багатомовних embedding-моделей вирішують цю проблему з боку векторного представлення. Замість зберігання контенту кожною мовою, система індексує документи один раз (зазвичай базовою мовою, часто англійською або польською), а багатомовні моделі забезпечують, що запит румунською та семантично близький запит польською потрапляють у схожий регіон векторного простору.

BGE-M3 підтримує понад 100 мов в одній моделі та доступний локально через Ollama, що означає, що запити клієнтів не залишають інфраструктури до етапу пошуку. Це важливо при роботі з персональними даними в запитах.

Три умови, які мають бути виконані, щоб ця архітектура працювала на практиці:

• Якість базового контенту: документи в індексі мають бути точними. Багатомовний embedding переносить якість і помилки вихідного контенту на всі мови.
• Генеративна модель з багатомовною підтримкою: LLM має не лише розуміти запит певною мовою, але й генерувати коректну відповідь. Не всі моделі однаково добре справляються з мовами Центральної Європи, як з англійською.
• Guardrails для кожної мови: фільтри ін'єкцій, поріг впевненості, тематичний обсяг мають працювати незалежно від мови вхідних даних. Асистент, який англійською відмовляється відповідати на запитання поза межами тематики, але чеською їх приймає, має прогалину в захисті.

Основний механізм багатомовного асистента — це детекція мови на вході та підтримка цієї мови протягом усього потоку відповіді. Варто розрізняти кілька рівнів:

Виявлення мови запиту відбувається детерміновано, перед викликом LLM. Бібліотеки, як langdetect або lingua-py, працюють локально, без мережевих затримок, і класифікують мову з впевненістю понад 95% для текстів довжиною понад 15 символів. Для коротких запитів ("статус", "допомога", "ціна") впевненість знижується, і система має або просити уточнення, або використовувати мову сесії за замовчуванням.

Підтримка мови в контексті діалогу важлива для асистентів, де розмова триває кілька турів. Клієнт, який почав англійською, а потім перейшов на польську, має отримати узгоджену відповідь. Проста схема: мова першого запиту в сесії стає мовою за замовчуванням, подальші зміни враховуються, але система не перемикається через окреме слово іншою мовою (запобігає перемиканню через випадковий англіцизм).

Маршрутизація до моделі: не кожна генеративна модель однаково добре підтримує всі мови. Шаблон, який використовується в промислових системах, — це LLM router, який на основі виявленої мови обирає модель з матриці. Мови з дуже хорошою покриттям у тренувальних даних (англійська, іспанська, французька, китайська, арабська) можуть спрямовуватися до універсальних моделей. Мови Центральної Європи (польська, чеська, словацька, румунська, угорська) можуть вимагати моделей з кращим покриттям цих даних або спеціально натренованих на цих мовах.

Запит клієнта (будь-яка мова)
        │
        ▼
[Виявлення мови — локально, детерміновано]
        │
        ▼
[PII masking — локально, до виходу з інфраструктури]
        │
        ▼
[Embedding BGE-M3 — локальний, багатомовний, 1024-dim]
        │
        ▼
[Векторний пошук — спільний індекс, hybrid search]
        │
        ▼
[Реренкінг — опціонально для top-k контекстів]
        │
        ▼
[LLM router — вибір моделі за мовою та завданням]
        │
        ▼
[Генерація відповіді мовою запиту]
        │
        ▼
[Guardrails — обсяг, впевненість, перевірка ін'єкцій]
        │
        ▼
Відповідь або human-handoff

Ключовий елемент — спільний індекс: документи індексуються один раз, hybrid search поєднує семантичний пошук з лексичним (BM25), а reranking покращує точність для запитів з мовними нюансами. Детальніше про архітектуру індексу — у статті семантичний пошук та ембедінги у компанії.

Для більшості компаній з 3-6 європейськими мовами та стандартним обслуговуванням клієнтів один хороший багатомовний модель з маршрутизатором до спеціалізованої моделі для мов Центральної Європи — це оптимальний вибір за співвідношенням вартості та якості.

Guardrails, які працюють лише однією мовою, створюють хибне відчуття безпеки. Кілька шаблонів збоїв, які виникають у системах, де guardrails проектувалися виключно для домінантної мови:

Ін'єкції через зміну мови: користувач пише англійською нормальну розмову, а потім вставляє інструкцію українською або арабською, сподіваючись, що фільтр не підтримує цю мову. Захист від prompt injection має працювати незалежно від мови вхідних даних, що означає або виявлення на рівні структурних шаблонів (спроба змінити роль, системна інструкція), або багатомовні шаблони виявлення.

Тематичний обсяг за мовою: якщо guardrail "не відповідай на запитання поза межами обслуговування клієнтів" визначений списком слів польською, він не спрацює для запитів угорською. Обсяг має визначатися на рівні семантичному: якщо cosine similarity запиту до тематичного простору нижче порогу, система відмовляється незалежно від мови.

Поріг впевненості та мова: моделі мають нижчу впевненість у відповідях для мов з меншим покриттям у тренувальних даних. Сталий поріг впевненості, який добре працює для англійської, може бути надто суворим для польської або надто м'яким для румунської. Пороги мають калібруватися за мовою або за мовною групою.

Human-handoff мовою клієнта: коли асистент ескалує питання до людини, повідомлення про ескалацію має бути мовою клієнта, а не системною мовою. "Передаю вас консультанту" замість технічних логів англійською.

Шаблони побудови guardrails для складних систем розглядаються у статті безпека агентів ШІ.

Багатомовність не змінює вимог RODO, але додає шари складності. Клієнти з різних країн ЄС підпадають під те саме регулювання, але місцеві наглядові органи (CNIL у Франції, BfDI у Німеччині, UODO в Польщі) можуть мати різні детальні рекомендації.

Чотири технічні вимоги, незалежні від мови:

• PII masking перед ембедінгом: імена, email-адреси, номери телефонів, номери замовлень з персональними даними маскуються локально, перш ніж запит потрапляє до шару ембедінгу або зовнішнього LLM. BGE-M3, що працює локально, не вимагає цього кроку, але більшість промислових систем поєднує локальні та хмарні моделі.
• Data residency: якщо обробляєш дані клієнтів з Німеччини, переконайся, що дані не залишають серверів ЄС. Багато хмарних провайдерів пропонують регіони ЄС, але self-hosting локальних моделей дає тут впевненість без необхідності аналізу договорів.
• Логи діалогів за мовою: логи для аудиту RODO мають містити інформацію про мову сесії. На запит доступу або видалення даних від франкомовного клієнта відповідь має бути надана французькою, а обсяг видалених даних має бути зрозумілим.
• Згода на багатомовну персоналізацію: якщо асистент використовує історію діалогів для персоналізації відповідей, згода на обробку даних з цією метою має бути надана та збережена для кожного користувача, незалежно від мови інтерфейсу.

Для систем, що обслуговують клієнтів з галузей охорони здоров'я, фінансів або дітей, слід провести DPIA перед впровадженням. Правові обов'язки у 2026 році розглядаються у статті AI Act та RODO 2026.

Багатомовний асистент схильний приховувати проблеми з якістю. Система виглядає коректно для мови, яку хтось у команді розуміє, але для мов, яких ніхто не знає на рівні носія, помилки можуть бути систематичними та залишатися непоміченими тижнями.

Три метрики, які варто відстежувати за мовою:

• Коефіцієнт ескалації за мовою: яка частка діалогів певною мовою закінчується передачею людині. Високий коефіцієнт для конкретної мови сигналізує низьку якість відповідей або погане покриття бази знань.
• Оцінка користувача за мовою: просте опитування після завершення діалогу (палець вгору/вниз або шкала 1-5). Порівняння оцінок для англійської, польської та румунської покаже нерівності якості.
• Затримка за мовою: багатомовні моделі можуть мати різний час генерації для різних мов через токенізацію. Мови з багатою морфологією (польська, чеська, угорська) генерують більше токенів з того самого тексту, що може впливати на latency.

Хороший моніторинг якості агента має розбивати метрики за мовою з першого дня продакшену, а не після появи скарг.

Вартість багатомовного асистента залежить від кількості мов, обсягу діалогів та обраної архітектури (локально vs. хмарні API). Пілот з однією додатковою мовою, окрім базової, зазвичай займає 2-4 тижні та включає розширення guardrails, тести якості відповідей та калібрування порогів. Кожна наступна мова при стабільній архітектурі вимагає менше роботи, оскільки інфраструктура вже готова.

Калькулятор ROI дозволяє ввести реальні обсяги запитів за мовою, погодинну ставку та поточний час обслуговування, щоб побачити термін окупності без "на око". Для компаній з 15%+ запитів мовами, відмінними від базової, багатомовний асистент зазвичай окупається швидше, ніж окремий найманий агент або ручний переклад кожного запиту.

Орієнтовні обсяги впроваджень:

Пілот завжди починається з мови з найбільшим обсягом запитів, окрім базової, а не з технічно найскладнішої.

Опишіть ваш поточний мовний обсяг та тип запитів клієнтів, а модель підкаже архітектуру та guardrails, підходящі для вашого випадку (playground: PII маскуються, нульове збереження):

Ні, при використанні багатомовних embedding-моделей, як BGE-M3, достатньо однієї бази знань базовою мовою. Модель відображає запити з різних мов у спільний векторний простір, тому семантичний пошук працює коректно незалежно від мови запиту. Переклад базового контенту на кожну мову є опціональним і виправданим лише тоді, коли документи містять ідіоматичні вирази, важкі для перекладу через embedding, або коли база містить дуже спеціалізований контент певною мовою.

Флективні мови, як польська чи чеська, складніші для моделей через багату морфологію та менше покриття в тренувальних даних порівняно з англійською. На практиці це означає вищий ризик граматичних помилок у відповідях та нижчу впевненість retrieval для запитів з рідкісними формами слів. Промисловий шаблон — це калібрування порогу впевненості окремо для цих мов та вищий коефіцієнт ескалації до людини на старті, який знижується в міру розширення бази знань. Моделі, як Bielik (польська) або багатомовні Mistral та Qwen з хорошим покриттям Центральної Європи, є кращим вибором, ніж моделі, оптимізовані виключно під англійську.

Перша причина — помилка виявлення мови на дуже коротких запитах. Рішення: при низькій впевненості детекції асистент запитує про мовні уподобання або використовує мову, визначену профілем користувача чи локацією сесії. Друга причина — модель, яка не може підтримувати мову протягом усієї розмови. Рішення: мова, виявлена на початку сесії, передається як системна інструкція до LLM при кожному виклику. Третя причина — відсутність контексту: якщо retrieved fragments лише однією мовою, модель може слідувати за цією мовою, а не за мовою запиту. Системна інструкція має явно наказувати відповідати мовою користувача незалежно від мови джерел.

AI Act не накладає спеціальних вимог виключно через багатомовність. Вимоги залежать від ризику застосування: асистент обслуговування клієнтів в e-commerce зазвичай є системою низького або обмеженого ризику, де потрібна насамперед прозорість (клієнт має знати, що спілкується з ШІ) та можливість ескалації до людини. Системи, що оцінюють кредитоспроможність, проводять рекрутинг або приймають рішення про доступ до базових послуг, класифікуються як високоризикові незалежно від мови. Детальний огляд обов'язків — у статті AI Act та RODO 2026. Якщо ваш асистент обслуговує клієнтів з кількох країн ЄС та обробляє чутливі дані, варто провести DPIA перед впровадженням у продакшен.

З вимірювання обсягу запитів за мовою за останні 3 місяці. Якщо одна мова становить понад 15% запитів, є бізнес-обґрунтування для пілоту. Наступний крок — оцінка якості поточної бази знань як кандидата на індекс RAG. Фрагментарний, неузгоджений або застарілий контент базовою мовою дасть погані результати всіма мовами. Як підготувати корпоративні дані для ШІ детально розглядає цей етап. Повна методологія впровадження від аудиту до пілоту — у статті з чого почати впровадження ШІ.