Обновить

Всем привет!

Сегодня поделюсь своим проектом, где использовал возможности открытых моделей LLM для создания автоматизированного конвейера по переводу англоязычных pdf-файлов в русскоязычные pdf. Как человек, интересующийся именно технологиями в области ИИ мне особенно было интересно максимальное приближенное к оригиналу сохранение содержимого переведенного материала, включая схемы, математические формулы, блоки кода (python) и bash-команд, рисунков (само собой), сохранение сносок, ссылок и пр. метаданных. Целью проекта было применение всевозможных доступных стеков и программ, использующих LLM в конкретной практической задаче. И как оказалось, на первый взгляд, простая задача перевода, с которой современная LLM, созданная и обученная на архитектуре трансформеров справляется на сегодняшний день блестяще, для pdf-формата оказалась не совсем простой (но и не скажу, что особо сложной).

О выборе программного стека технологий. Здесь во многом все определило глубина моих познаний и практических умений работать с LLM-моделями и тем оборудованием (потребительским, конечно), которое имеется дома. Поэтому, исходя из пары-тройки (пары) вычислительных узлов (ноутбуков) в домашней локалке мой выбор определил следующие программные и аппаратные компоненты.

Программные компоненты. Прежде всего это среда выполнения wsl. Просто работает в windows, удобна мне как новичку. В wsl установка обычной env стандартным python. И далее уже конкретные ПО для выполнения задачи перевода pdf на русский. Тут пришлось почитать в сети что есть свободное (исходя из цели использования только открытого ПО и LLM, чтобы оценить уровень их развития). Были опробованы такие программы как Docling, Marker-pdf и еще какую-то). В итоге, для извлечения из pdf в markdown формат я использовал Marker-pdf. У него имеется целый набор специализированных ocr-моделей для парсинга содержимого pdf. Marker в режиме конвейера осуществляет извлечение в указанную папку все содержимое исходного pdf в виде отдельных jpg-файлов, файла метаданных и итогового англоязычного .md файла. Для обратного процесса конвертации переведенного на русский язык ru.md я использовал WeasyPrint и Pandoc. Мой выбор - Pandoc. Сложнее, но поддержка xeLatex и куча настроек через опции командной строки и переменных окружения wsl. Pandoc - единственное ПО в моем конвейере, которое не использует LLM. И собственно, середина - перевод. Готовый скрипт на python. Перевод разбитых на части (chanks) в endpoint LLM - requests.post. Фишкой является url, который через специальный балансировщик, управляющий вычислительными узлами в локалке отправляется в requests.post. Получается параллельный перевод на нескольких узлах с  развернутыми OpenAI-совместимыми LLM. Количество узлов - сколько найдется в домашней ИИ лаборатории))). До и после отправки на перевод в LLM - чистка регулярками от различных костылей и защиты от перевода не нужных элементов (чистка колонтитулов, пагинация, сглаживание двойных переносов строк, изоляция спец. блоков от LLM блоков кода, мат. формул, кода внутри строк, приведение кода к pep8), подготовка переведенного _ru.md к сборке pdf-файла в Pandoc. В итоге - pipeline в 3 шага: Marker-pdf, Скрипт-переводчик на python, Pandoc.

Основные шаги перевода (marker, python скрипт, pandoc)
Основные шаги перевода (marker, python скрипт, pandoc)

Все вместе также можно запустить скриптом bash-сценария:

Использование: ./pipeline.sh <path_to_input_pdf> <output_path> [page_range]

Пример1: перевод всего Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings

Пример1: перевод первых 21 страниц Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings 0-20

Репозиторий на github DemonODG/pdf-translator: English-to-Russian PDF Translation Pipeline

Это мой первый пост на тему применения современных LLM моделей в различных практических задачах. Если это вызовет интерес в более подробном описании данного pipeline - напишу статью поподробнее.

Всем добра!

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии0

Я попал к психиатру из‑за кодинга с AI

Со стороны программирование звучит как медитативное занятие. Сидишь себе за компом целый день, слушаешь музыку, пьешь вкусный кофе. У все меня примерно так и происходит. Сначала я не спеша пытаюсь выстроить в голове то, что требуется сделать. Именно «не спеша». И не потому что я такой опытный и мудрый, а потому что быстро я просто не умею.

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

Все это звучит конечно логично, но явно 10x инженером так не стать. Да и будем честны, даже 2x тоже. В IT, где эффективность, это не один из критериев оценки сотрудника, а недостижимая цель, к которой стремятся все. Мой стиль работы — это проблема. Но благодаря появлению AI, эта проблема стала решена.

Я попал к психиатру из‑за кодинга с AI

Публикации