Додавання бенгальської, суахілі та хауса до суверенного гуманітарного асистента

Наш гуманітарний асистент відповідає на запитання про нормативний канон сектору — Sphere Handbook, Женевські конвенції, Конвенцію про статус біженців 1951 року та споріднені документи — на основі корпусу, який ми самостійно завантажуємо та ембедимо, за межею вихідного трафіку, де кожен виклик моделі журналюється, деперсоналізується та є атрибутованим. Корпус — англомовний. Люди, яким він потрібен, часто не володіють англійською.

Тож ми вирішили додати три мови: бенгальську, суахілі та хауса. Разом вони охоплюють гуманітарні контексти від Кокс-Базару до Сахелю. Кожна окремо — це дуже різна інженерна задача, і ми знаємо це лише тому, що виміряли кожну з них, перш ніж щось будувати.

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

Чотири рівні, чотири способи зазнати невдачі

Мова не стає «підтримуваною» лише тому, що так написано в картці моделі. Для користувача, який пише бенгальською, мають безвідмовно працювати чотири незалежні рівні:

1. Виявити — визначити, якою мовою написано повідомлення. Наша наявна евристика, побудована для світу української/російської/англійської мов, класифікувала всі три нові мови як англійську.
2. Знайти — відшукати потрібні англомовні фрагменти за запитом, написаним іншою мовою. Міжмовний пошук — це завдання моделі ембедингів.
3. Згенерувати — відповісти мовою користувача, спираючись на англомовні докази, не звертаючись до провайдера, який порушує принцип суверенності.
4. Відредагувати — виявити імена, номери телефонів та національні ідентифікаційні номери до того, як щось перетне периметр. У разі збою — блокувати, і для кожної мови окремо.

Кожен рівень може дати збій самостійно, але виявляється, що для кожної мови вони відмовляють по-різному.

Спершу виміряти, нічого не орендувати

Перш ніж визначатися з архітектурою (чи будь-яким GPU), ми провели два зондувальні тести на безсерверному, потокенному європейському рівні інференсу. Близько 2900 викликів моделі, менш ніж п'ять євро, жодного розгорнутого інстансу.

Ці тести успадкували дисципліну оцінювання, за яку ми вже «заплатили навчання» на англомовному стеку:

• Повторювати все. Наше оцінювання має відомий поріг шуму (~4 бали за 100-бальною шкалою між ідентичними прогонами). Будь-яке порівняння одного прогону, менше за цей поріг, вимірює лише настрій генератора. Кожне число нижче — це середнє з трьох прогонів із зазначеним розкидом.
• Оцінювати пошук окремо від генерації. Об'єднання цих оцінок унеможливлює спостережуваність.
• Перевіряти свої переклади. Питання для оцінювання були машинно перекладені, а потім перевірені зворотним перекладом незалежною моделлю, тоді як третя модель оцінювала семантичну еквівалентність. Частка тих, що пройшли перевірку: бенгальська 32/40, суахілі 25/40, хауса 22/40 — і одна позначка бенгальською виявилася тихою підміною «кору» на «холеру». Це вже саме по собі є висновком: машинно перекладений контент потребує перевірки, хоч би що ви робили з діалогом.
• Не довіряти своєму судді. Результати для хауса були повністю переоцінені другою моделлю з іншого сімейства. Ранжування вижило; абсолютні числа змінилися. Наводьте обидва.

Висновок 1 — Генерація: одна модель мовно-однорідна

Ми надали трьом моделям-кандидатам правильні англомовні докази та запитання кожною мовою, вимагаючи відповіді тією ж мовою. Це повністю ізолює міжмовну генерацію від пошуку.

Одна модель — Gemma — тримає власний англомовний показник у «вилці» для всіх трьох мов. Одна модель повністю провалює хауса. А найпоказовіший збій узагалі стосувався не показників: mistral-small у 32% випадків відповідав на запитання бенгальською англійською, попри явні інструкції. Зі змістом усе було гаразд, а от з мовною відповідністю — ні. Суддя на основі LLM послідовно це пропускав — п'ятирядковий скрипт, що перевіряв юнікод-скрипт відповіді, ловив це щоразу. Дешеві детерміновані перевірки перевершують моделі-судді всюди, де таку перевірку можна написати.

Висновок 2 — Пошук: дзеркальне відображення

Далі ті самі запитання були спрямовані як запити до реального корпусу, щоб перевірити, чи здатна наша модель ембедингів (bge-m3) знаходити англомовні фрагменти за неанглійським текстом. Англомовний контроль точно відтворив наш продакшн-базовий показник — завжди перевіряйте тестовий стенд, перш ніж довіряти йому.

Бенгальська показує пошук на рівні англійської. Хауса ж провалюється — і шум від машинного перекладу було виключено повторним оцінюванням лише на перевірено чистих перекладах (результат той самий). Модель ембедингів просто «не бачила» достатньо хауса, що узгоджується з тим, що про цей клас моделей повідомляє література з пошуку африканськими мовами (AfriMTEB).

Поставте ці два висновки поруч — і архітектура спроєктує себе сама:

Ми виміряли цей поворот того ж дня: переклад запитів хауса англійською за допомогою NLLB-200 (дистильована модель на 1,3 млрд параметрів, на CPU, секунди на запит) підняв пошук із 0,37 MRR до 0,70 — вище за нативну суахілі — і скоротив кількість запитань без жодного знайденого результату з 15 до 2. Мова, яку вранці ми назвали б непридатною для обслуговування, до вечора отримала перевірену наскрізну архітектуру, а виправлення коштує кроку перекладу тривалістю в секунди CPU для запитів однієї мови.

Висновок 3 — Редагування конфіденційних даних: усі пастки безшумні

Рівень приватності виявився найбільшою прогалиною: галузевий стандартний фреймворк для PII взагалі не має моделей для цих мов. Ми додали другий сервіс-аналізатор — трансформерні NER-моделі, натреновані на корпусах африканських мов та бенгальської, — не чіпаючи наявний, уже виміряний аналізатор. Два сервіси — щоб розширення охоплення ніколи непомітно не погіршило те, що вже виміряно.

Вимірювання повноти (recall) перед розгортанням виявило три дефекти, кожен з яких залишився б непоміченим під час рев'ю коду:

1. Редактор маскував слово «бенефіціар», але пропускав саме ім'я. Токенізатор бенгальської моделі відкидає діакритичні голосні знаки; за агрегації спанів за замовчуванням фрагменти імені губилися під час вирівнювання. Одне значення конфігурації (aggregation: max) виправило це — але лише вимірювання повноти могло б це коли-небудь показати.
2. Контекстний підсилювач фреймворку жодного разу не спрацював. Шаблони ідентифікаторів набирали бал трохи нижче порогу редагування, хоча стояли поруч із ідеальним контекстним словом («NID», «kitambulisho»), тому що багатомовний токенізатор не надає підсилювачу лем для зіставлення. Числа виглядали правдоподібно; вони систематично були на одну позначку заниженими.
3. «Common Article 3» перетворилася на <PERSON_1>. Хаусою NER-модель позначила початок цитати із запитання про Женевські конвенції як особу — що тихо знищило б один із найважливіших запитів у корпусі. Списки дозволеної предметної лексики існують саме для таких випадків.

Розгорнута система зараз показує повноту 120/120 на нашому розміченому корпусі — і ми публікуємо це число з приклеєним застереженням: корпус побудований за тими самими правилами формату, які закодовані в розпізнавачах, тож частина цього показника — тавтологічна. Коли наша редакція для української/російської зустрілася зі справді відкладеним (held-out) тестовим набором, ~100% перетворилися на 84,2%. Саме це число ми наводимо для цих мов, а три нові мови не отримають публічного числа, доки не з'являться їхні відкладені набори. Показник повноти без вказаного походження — це маркетинг, а не доказ.

Висновок 4 — Вимірювання окупається помилками, яких ви не шукали

Роблячи рівень лексичного пошуку чутливим до Юнікоду (раніше він відкидав кожен бенгальський символ), ми виявили, що токенізатор ніколи не розпізнавав українську літеру «ї» — прогалину в один символ у регулярному виразі, яка з моменту випуску функції безшумно фрагментувала більшість українських слів у пошуку за ключовими словами. Ніхто цього не помітив, бо гібридний пошук деградував плавно, а не відмовляв повністю. Цю помилку виявив не звіт про баг, а зонд, який відмовився видавати осмислене число.

Той самий патерн повторювався весь день. Перевірка якості зворотним перекладом позначила 32 з 40 перекладів хауса як зіпсовані — доки ми не перевірили сам «перевіряльник» і не з'ясували, що саме модель зворотного перекладу неправильно читала хауса («туалет» перетворився на «відстань від дому»). Заміни читача — і 22 з 40 виживають. Кожен вимірювальний інструмент сам є об'єктом, який потрібно вимірювати.

Питання самостійного хостингу — нарешті з числом

Останній експеримент сесії стосувався іншого давнього питання: скільки насправді коштує якість при самостійному хостингу продакшн-моделі? Ми обслуговували ту саму модель обома способами — хостований API з повною точністю та 4-бітну квантизовану копію на власному GPU — і провели ідентичне оцінювання, тричі для кожного варіанта.

Квантизація до int4 коштує близько 6 балів, що виходить за межі шуму обох варіантів. Це перетворює розмиту архітектурну дискусію на чітке правило прийняття рішень: не спрямовувати чутливий до якості трафік на int4-варіант за паритету ціни. Самостійний хостинг продають за те, для чого він насправді призначений — вимогу суверенності, за яку платить клієнт, — з наперед заявленою виміряною вартістю якості, а FP8 на обладнанні продакшн-класу стоїть у черзі як тест на паритет.

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

У що це обійшлося і чого ми досі не знаємо

Усе дослідження — два зондувальні тести на чотирьох мовах і трьох моделях, експеримент із поворотом у пошуку, розгорнуте та перевірене розширення редагування конфіденційних даних і кількісно обґрунтоване рішення щодо самостійного хостингу — коштувало однозначної кількості євро в токенах API та нуль орендованих GPU-годин. На дороге на вигляд питання («чи потрібен нам GPU за €1000/місяць?») відповіли за ціну кави, і відповідь була така: «поки що ні, і ось число, яке підкаже нам, коли це зміниться».

Так само важливо те, чого докази поки що не підтверджують, — саме публікація цього списку робить решту заслуговуючою на довіру:

• Повнота редагування 120/120 — це доказ коректності «підключення», а не продакшн-твердження: спочатку потрібні відкладені набори для кожної мови.
• Показники зондувальних тестів — не продакшн-показники; еталонні докази роблять генерацію легшою, ніж реальний цикл пошуку.
• Переклади пройшли лише машинну перевірку якості; рев'ю носіями мови для всього, що бачить користувач, ще попереду.
• Виявлення мови вимірюється на нашому оцінювальному реєстрі, а не на розмовному чаті, перемиканні кодів чи романізованій бенгальській.
• Кожне наведене вище число — це середнє за повторюваними прогонами з указаним розкидом, а показники генерації для хауса несуть більше невизначеності, ніж інші, бо навіть два судді — це все ще лише два судді.

Головний висновок — це метод. Ніщо тут не вимагало рідкісної інфраструктури чи дослідницького бюджету. В основі — архітектурні рішення, ухвалені на основі вимірювань, і ставлення до кожного дивного числа спершу як до запитання про сам інструмент, і лише потім — як до факту про світ.

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

Як бонус, ми застосували той самий принцип «спершу виміряй» до самого сайту: baena.ai тепер має машинний переклад бенгальською, суахілі та хауса — тими самими трьома мовами, про які йдеться в цій статті, — щоб цей матеріал і решта сайту стали доступнішими для тих, кому вони насправді потрібні.