Арабский OCR 2026: полное тестирование VLM моделей, которые не умеют читать

Парадокс 2026 года: VLM умеют генерировать код, но не читают арабский паспорт

Представьте ситуацию: у вас есть сканы арабских документов - паспорта, контракты, медицинские карты. Нужно автоматизировать обработку. Вы идете за последними open-source VLM моделями на Hugging Face - их десятки, все обещают понимание текста на изображениях. Идеально, правда?

А теперь реальность, которую я проверил лично на 50+ документах: большинство моделей просто не работают с арабским текстом. Они видят латинские буквы, кириллицу, но арабскую вязь превращают в случайный набор символов или вообще игнорируют.

Что я тестировал и зачем это вам

Я взял реальные производственные документы из трех источников:

• Арабские паспорта и ID-карты (сложная структура, официальные шрифты)
• Медицинские рецепты (рукописный текст, смесь арабского и латиницы)
• Юридические контракты (мелкий печатный текст, сложная верстка)

И прогнал их через все популярные VLM модели, которые были актуальны на январь 2026 года. Критерии простые: точность распознавания, скорость, стабильность ответов, стоимость (для облачных).

Победитель, который разочаровал: Gemini 2.0 Multimodal

Давайте сразу к главному. После недели тестов единственная модель, которая более-менее стабильно работала с арабским текстом - Gemini 2.0 Multimodal от Google.

Почему это разочарование? Потому что Gemini - облачная проприетарная модель. Вы не можете запустить ее локально, не можете дообучать на своих данных, платите за каждый запрос. И все равно это лучшее, что есть на рынке в январе 2026.

Как работает Gemini с арабским

У Gemini есть две ключевые особенности, которые дают ей преимущество:

1. Направленность текста справа налево - модель понимает, что арабский читается справа налево, и сохраняет этот порядок в ответах
2. Контекстное понимание диакритики - точки, хамзы, ташкиль она распознает лучше конкурентов

Пример промпта, который работает:

prompt = """
Прочитай текст на изображении. 
Текст на арабском языке, читается справа налево.
Выведи результат в виде чистого текста, сохранив диакритические знаки.
"""

Без указания "читается справа налево" точность падает на 15-20%. Модели нужно явно говорить об особенностях языка.

Провал open-source: почему Qwen3-VL и другие не справляются

Я тестировал Qwen3-VL-8B - последнюю версию на январь 2026. Результаты удручающие:

• Смешивает арабский и латинские буквы (арабская "ب" становится латинской "b")
• Игнорирует диакритические знаки
• Часто переворачивает направление текста (читает слева направо)
• Высокий уровень hallucination - добавляет слова, которых нет в оригинале

Проблема в обучающих данных. Большинство open-source VLM обучали на:

1. Английских текстах (80%+ датасетов)
2. Китайских текстах (15%)
3. Остальные языки - случайные примеры

Арабский обычно попадает в третью категорию. Модель видела несколько тысяч примеров против миллионов англоязычных. Результат предсказуем.

Hallucination в арабском OCR: особая жестокость

Если с английским VLM иногда "додумывают" слова, то с арабским происходит нечто иное. Модели начинают:

• Менять смысл через диакритику - одна точка меняет букву, а с ней и значение слова
• Путать изолированную и начальную формы - арабские буквы меняют форму в зависимости от позиции
• Игнорировать лигатуры - специальные соединения букв, характерные для арабского

Пример из тестов: в паспорте было слово "مصري" (египетский). LLaVA-NeXT прочитала как "مصرى" - технически похоже, но с другой конечной буквой. Для человека-носителя разница очевидна, для модели - нет.

Почему это критично для документов

В юридических и финансовых документах одна ошибка в слове может:

1. Изменить сумму контракта
2. Исказить имя или фамилию
3. Сделать документ юридически недействительным

Я видел случаи, когда модель "исправляла" дату рождения в паспорте, потому что цифры на арабском показались ей ошибкой. (Арабские цифры отличаются от привычных нам 0-9, используются свои символы).

Пошаговый план: как тестировать VLM для ваших документов

1 Подготовьте эталонный датасет

Не тестируйте на 2-3 документах. Соберите 50-100 реальных документов, которые представляют ваши use case. Разметьте их вручную - это займет день, но сэкономит недели позже.

Включите разные типы:

• Печатный текст (официальные бланки)
• Рукописный текст (подписи, пометки)
• Смешанный контент (текст + таблицы + изображения)
• Разное качество сканов (от идеальных до фотографий на телефон)

2 Создайте метрики, которые имеют смысл

Точность (accuracy) - это хорошо, но недостаточно. Добавьте:

metrics = {
    'character_accuracy': calculate_char_accuracy,
    'word_accuracy': calculate_word_accuracy,
    'critical_field_accuracy': calculate_critical_fields,  # Имена, даты, суммы
    'hallucination_rate': count_hallucinations,
    'direction_preservation': check_rtl_preservation  # Сохранение направления текста
}

Для арабского critical_field_accuracy и direction_preservation часто важнее общей точности.

3 Тестируйте с разными промптами

Одна и та же модель может показывать разную точность в зависимости от промпта. Тестируйте вариации:

• Без указания языка
• С явным указанием "арабский язык"
• С указанием "текст справа налево"
• С просьбой сохранить диакритические знаки

Пример из моих тестов: Gemini без указания RTL - 70% точности, с указанием - 88%. Разница в 18% только из-за промпта.

4 Проверьте стабильность, а не только точность

Запустите каждый документ через модель 3-5 раз. Посмотрите на вариативность ответов. Если модель каждый раз выдает разный текст - это красный флаг для production.

Особенно важно для облачных моделей: проверяйте, не зависит ли результат от времени суток, нагрузки на сервис. (Да, такое бывает).

Специфические проблемы арабского текста, которые ломают VLM

Проблема 1: Ташкиль (диакритические знаки)

Арабские диакритические знаки (харакат) указывают на гласные звуки. В печатных документах их часто опускают, но в Коране, учебниках, официальных бумагах - они есть. Большинство VLM либо игнорируют ташкиль, либо неправильно их интерпретируют.

Почему это важно? Без ташкиль слово "كتب" можно прочитать как "катаба" (он писал), "кутиба" (было написано) или "кутуб" (книги). Контекст помогает человеку, но не модели.

Проблема 2: Формы букв

Арабская буква меняет форму в зависимости от позиции в слове: изолированная, начальная, срединная, конечная. Для модели это 4 разных символа, которые нужно связать. Многие VLM не умеют этого делать.

Пример: буква "ب" (ба). В изолированной форме выглядит как "ب", в начальной - как "بـ", в срединной - "ـبـ", в конечной - "ـب".

Проблема 3: Лигатуры

Некоторые сочетания букв в арабском пишутся как специальные символы (лигатуры). Самые частые: "لا" (лям-алиф), "ﻻ" (изолированная форма). Модели часто разбивают лигатуры на отдельные буквы, что технически правильно, но визуально не соответствует оригиналу.

Альтернативы: когда VLM не подходят вообще

После всех тестов я пришел к выводу: для production-систем обработки арабских документов в 2026 году VLM - не всегда лучшее решение.

Рассмотрите классические OCR движки с постобработкой:

1. Tesseract 5.3+ с арабским языковым пакетом - бесплатно, можно дообучать, стабильные результаты для печатного текста
2. EasyOCR с арабской моделью - лучше с рукописным текстом, но требует GPU
3. Специализированные коммерческие решения - ABBYY FineReader, Adobe Acrobat (дорого, но работают)

Где тогда использовать VLM? В сложных случаях:

• Документы со смешанным контентом (текст + таблицы + схемы)
• Извлечение структурированных данных (понимание, что где находится)
• Документы очень плохого качества, где классический OCR падает

Как я писал в статье про падения VLM на сканах, иногда гибридный подход работает лучше: классический OCR для текста + VLM для понимания структуры.

Прогноз на 2026-2027: что изменится

Судя по roadmap основных игроков:

1. Open-source догонят по арабскому к середине 2026 - появляются датасеты типа "ArabicVLM-Bench"
2. Специализированные VLM для документов - модели, обученные только на документах, а не на общих изображениях
3. Локальные Gemini-подобные модели - Google обещает выпустить уменьшенные версии для локального запуска

Но прямо сейчас, в январе 2026, выбор невелик. Либо платите за Gemini и миритесь с облачной зависимостью, либо используете классические OCR и теряете в качестве на сложных документах.

Мой совет на ближайшие 6 месяцев

Если нужно запустить систему сегодня:

1. Начните с Tesseract + языковой пакет для арабского
2. Для сложных случаев добавьте Gemini API как fallback
3. Собирайте данные о ошибках - они понадобятся для дообучения
4. Планируйте переход на open-source VLM во второй половине 2026, когда появятся нормальные арабские модели

И последнее: не верьте маркетингу. "Мультиязычная поддержка" в 95% случаев означает "английский + китайский + случайные примеры других языков". Тестируйте на своих данных. Всегда.

FAQ: частые вопросы после тестирования

Можно ли дообучить Qwen3-VL на арабских документах?

Технически - да. Практически - нужно 10-20 тысяч размеченных изображений, несколько A100 на месяц и экспертиза в тонкой настройке VLM. Для большинства компаний проще и дешевле использовать Gemini сейчас и перейти на open-source позже.

Почему арабский сложнее, чем китайский или хинди?

Три фактора: направление письма (RTL), формы букв, диакритические знаки. Китайский хотя бы пишется слева направо и символы не меняют форму. Арабский сочетает все сложности.

Стоит ли ждать арабско-специализированных VLM?

Они уже появляются. Но проблема в данных - качественных размеченных арабских документов мало. Большинство датасетов - это скриншоты из интернета, а не реальные сканы паспортов и контрактов. Так что специализированные модели будут лучше на тестах, но хуже в production.

Как проверить, не hallucinate ли модель?

Простой тест: дайте ей один и тот же документ 5 раз. Если ответы различаются больше чем на 5% - модель нестабильна. Особенно обращайте внимание на критические поля (имена, даты, суммы). Если они меняются между запусками - модель нельзя использовать в production.

Ошибка, которую совершают все в начале

Самая частая ошибка - тестировать на 2-3 "идеальных" документах. "Вот паспорт, отсканированный на профессиональном сканере с 600 DPI". Реальность: фотография на iPhone под углом, блики, тени, плохой фокус.

Тестируйте на худшем, что может прийти в вашу систему. Если модель работает на плохих данных, на хороших она точно сработает. Обратное неверно.

И еще: не экономьте на разметке тестового датасета. Потратьте неделю, чтобы разметить 100 документов вручную. Это сэкономит месяц на переделке системы позже.

Удачи с арабскими документами. И да, держите под рукой контакты носителя языка для проверки. Пока ИИ не научился читать арабский как человек, эта мера предосторожности не помешает.