Почему ваш RAG для арабских документов уже сломан
Вы загрузили пачку арабских PDF с финансовыми отчетами. Запустили стандартный пайплайн. Ждете точные ответы на вопросы про выручку по регионам. Получаете бессвязную абракадабру с перепутанными столбцами таблиц. Знакомая история? Я потратил три месяца и пару неудачных проектов, чтобы понять: обработка арабских документов — это не "просто включить другую модель OCR". Это отдельная инженерная дисциплина.
Особенно больно с таблицами. Арабский текст читается справа налево. Цифры и латиница — слева направо. Диакритические знаки (ташкиль) меняют смысл слова. Соединение букв зависит от позиции в слове. Стандартные инструменты ломаются на первом же сложном документе.
Реальный кейс из практики: клиент потерял $12,000 на неправильно обработанных контрактах из-за ошибок в извлечении табличных данных. Цифры в столбцах перепутались — финансовый анализ стал бессмысленным.
1Шаг первый: выбиваем текст из документа, но с умом
Начинающие берут Tesseract с арабским языковым пакетом. Получают кашу. Потому что Tesseract слаб на сложном форматировании и плохо понимает контекстные формы арабских букв.
Что работает лучше:
- Unstructured — отлично справляется с сохранением структуры, но требует точной настройки под арабский
- LlamaParse от Groq — показывает хорошие результаты с многоязычными документами
- Donut или TrOCR — модели на основе трансформеров, которые можно дообучить на арабских данных
Но даже лучший OCR даст сырой текст с ошибками. Диакритические знаки часто теряются. Буквы в разных позициях (изолированная, начальная, срединная, конечная) могут распознаваться как разные символы. Это ломает последующий семантический поиск.
2Шаг второй: нормализация — где теряется смысл
Вы извлекли текст. Теперь нужно привести его к единому виду. Арабский язык имеет несколько форм представления одних и тех же символов в Unicode. Буква "алиф" может быть представлена как U+0627 (арабская буква алиф) или U+FE8D (арабская буква алиф в изолированной форме). Для поисковых систем и эмбеддингов это разные символы.
| Проблема | Решение | Инструмент |
|---|---|---|
| Разные формы букв в Unicode | Нормализация NFC/NFD | Python unicodedata.normalize() |
| Диакритические знаки потеряны | Опциональное удаление или сохранение | Arabica или camel-tools |
| Смешение направлений текста | Bidirectional алгоритмы | ICU Bidirectional или python-bidi |
Самый опасный момент — диакритика. Удалите все ташкиль — упростите поиск, но потеряете смысловые различия. Оставьте — получите шум в эмбеддингах. Мой совет: создайте две версии текста. Очищенную (без диакритики) для поиска по смыслу. Полную — для точного цитирования в ответах RAG.
3Шаг третий: таблицы — адский уровень сложности
Вот где стандартные инструменты умирают. Таблица на арабском — это смешение RTL (текст) и LTR (цифры, даты). Столбцы идут справа налево. Заголовки столбцов — на арабском. Данные внутри — смесь арабского и чисел. При извлечении все переворачивается.
Как НЕ надо делать: использовать стандартный PDF-парсер типа PyPDF2 или pdfplumber. Они не понимают логическую структуру арабских таблиц и возвращают текст в непредсказуемом порядке.
Что работает:
- Визуальные трансформеры — модели типа Table Transformer от Microsoft. Они анализируют изображение страницы, а не текст. Видят границы ячеек, объединенные столбцы, структуру.
- Специализированные инструменты — Camelot для таблиц в PDF, но требует точной настройки под RTL.
- Кастомный пайплайн — сначала извлекаем таблицу как изображение, затем применяем модель для обнаружения таблиц, потом OCR внутри каждой ячейки с учетом направления текста.
После извлечения нужно сохранить семантику. Каждая ячейка должна храниться с метаданными: номер строки, столбца, заголовок. Иначе ваш RAG не сможет ответить на вопрос "Какая выручка была в Эр-Рияде в 2023 году?".
4Шаг четвертый: чанкинг, который не режет слова
Стандартный чанкинг по символам или предложениям ломает арабский текст. Потому что предложения на арабском часто длиннее. И потому что разрыв может прийтись на соединение между буквами.
Инструменты:
- Semantic Text Splitter — разбивает по смыслу, а не по количеству символов
- Кастомный разделитель — на основе заголовков (عنوان, القسم) и маркеров абзацев
- Для таблиц — сохраняйте каждую строку как отдельный чанк с контекстом заголовков столбцов
Размер чанка — отдельная история. Для арабского текста я увеличиваю размер на 20-30% по сравнению с английским. Потому что информационная плотность выше (корневые системы, меньше пробелов).
5Шаг пятый: эмбеддинги и поиск — последняя мина
Вы прошли OCR, нормализацию, извлекли таблицы, разбили на чанки. Теперь нужно создать векторные представления. И вот здесь многие мультиязычные модели спотыкаются.
Модели типа sentence-transformers/all-MiniLM-L6-v2 работают с арабским, но не оптимально. Они обучены в основном на английских данных. Арабские слова получают слабые эмбеддинги.
| Модель | Плюсы для арабского | Минусы |
|---|---|---|
| multilingual-e5-large | Хорошее качество на многих языках | Тяжелая, требует ресурсов |
| Arabic BERT | Специализирована на арабском | Только для текста, нет мультимодальности |
| Jina Embeddings v3 | Поддержка 100+ языков | Может быть избыточной |
Мой выбор — использовать специализированные арабские модели или дообучать мультиязычные на своих данных. Для гибридного поиска добавьте BM25 с учетом морфологии арабского языка. Это дает +30-40% к точности по сравнению с чистым векторным поиском.
Собираем пайплайн воедино
Теперь из этих пяти шагов собираем pipeline, который не сломается на первом же документе с таблицей.
- Извлечение с сохранением структуры — LlamaParse для общего текста + Table Transformer для таблиц
- Нормализация в два прохода — чистая версия для поиска, полная для ответов
- Обработка таблиц отдельно — сохраняем координаты ячеек, заголовки, связи
- Семантический чанкинг — разный для текста и таблиц
- Специализированные эмбеддинги + гибридный поиск с учетом морфологии
Интегрируем это в семантический пайплайн для LLM, добавляем валидацию качества на каждом этапе.
Самая частая ошибка на этом этапе: пытаться обрабатывать все документы одним потоком. Арабские таблицы требуют отдельного, более ресурсоемкого конвейера. Не экономьте на этом — разделите потоки обработки текста и таблиц.
Что делать, когда документы смешанные
Реальность: у вас будут документы на арабском с вкраплениями английского (термины, имена собственные). Или таблицы, где один столбец на арабском, другой — на английском.
Решение: используйте мультиязычные модели OCR и эмбеддингов. Но настройте детектор языка на уровне фрагментов, а не всего документа. Для таблиц — определяйте язык каждой ячейки отдельно. Это ресурсоемко, но необходимо для точности.
Для особо сложных случаев смотрите в сторону VLM моделей типа Qwen3-VL, которые понимают и текст, и визуальное расположение элементов.
Чеклист перед запуском в production
- Тестовый набор из 50+ документов разной сложности (сканы, цифровые PDF, таблицы, смешанные языки)
- Метрики качества на каждом этапе: точность OCR, сохранение структуры таблиц, качество поиска
- Фолбэк-механизмы: если модель не уверена в распознавании таблицы — отправляем документ на ручную проверку
- Мониторинг дрейфа: периодически тестируем pipeline на новых типах документов
- Кеширование эмбеддингов для одинаковых документов — экономит 60% вычислительных ресурсов
Главный совет, который сэкономит вам месяцы работы: начните с небольшого, но репрезентативного датасета. Обработайте его вручную — это будет ground truth. Затем сравнивайте каждый этап вашего пайплайна с этим идеальным результатом. Только так вы найдете слабые места до того, как клиенты найдут их за вас.
Арабские документы в RAG — это не просто еще один язык. Это отдельный мир со своими правилами. Игнорировать эти правила — гарантировать провал проекта. Следовать им — получить конкурентное преимущество на рынке, где большинство до сих пор бьется с кривыми таблицами и перепутанными столбцами.
P.S. Если думаете, что это слишком сложно — посмотрите на альтернативу. Одна ошибка в финансовом отчете из-за неправильно извлеченной таблицы может стоить дороже, чем разработка правильного пайплайна. Вопрос не в том, делать или не делать. Вопрос в том, сколько вы готовы потерять, делая это неправильно.
