Программа для извлечения текста из PDF, раньше работавшая только в командной строке, теперь запускается прямо в браузере. Никакого сервера, никакой загрузки файлов наружу. Разработчик Саймон Уиллисон пересобрал её с помощью ИИ-ассистента Claude Code (инструмент для автоматизации программирования от компании Anthropic) за 59 минут. В этом кейсе интересен не столько сам трюк, сколько архитектурный сдвиг, важный для всех, кто работает с чувствительными документами.
LiteParse — это инструмент с открытым исходным кодом (open source), созданный компанией LlamaIndex для извлечения текста из PDF-файлов. Изначально он существовал как программа, запускаемая в командной строке (среде Node.js). Пользователь набирал команду, указывал файл, и на выходе получал структурированный текст. Всё работало, но с одним важным ограничением: PDF нужно было принести на тот компьютер, где установлен LiteParse. Разработчик и журналист Саймон Уиллисон увидел в этом не недостаток, а возможность — перенести обработку на сторону клиента, прямо в браузер. Результат стоил потраченных 59 минут.
Как LiteParse разбирает PDF без единой языковой модели
В отличие от модных решений, которые подключают большие языковые модели (LLM) к каждой задаче, LiteParse использует классический пространственный анализ (spatial text parsing). Задача обработки PDF далеко не сводится к простому считыванию символов. Страница может содержать колонки, сноски, подписи к картинкам, плавающие блоки. Если просто собрать все символы подряд, получится нечитаемая каша. LiteParse анализирует геометрию страницы: определяет колонки, группирует текстовые блоки и восстанавливает логический порядок чтения. Для случаев, когда текстовый слой отсутствует — например, скан документа, — подключается система оптического распознавания символов Tesseract.js. Вся эта логика построена на библиотеке PDF.js (проект Mozilla для отображения PDF в браузере) и порте Tesseract на WebAssembly (технология, позволяющая выполнять сложный код прямо в браузере). Именно эта связка позволила предположить: а что если всё заработает прямо у пользователя, без сервера?
59 минут от идеи до работающего веб-приложения
Сам процесс переноса интересен не столько скоростью, сколько инженерным подходом. Уиллисон не просил Claude Code «сделать красиво». Сначала он вручную проверил гипотезу на смартфоне — загрузил случайный PDF и спросил ассистента, можно ли запустить LiteParse в браузере. Затем на ноутбуке он создал копию репозитория (хранилища кода) LlamaIndex, записал заметки в файл notes.md и попросил модель сгенерировать plan.md — детальный план реализации. Только после этого он отдал конкретную команду: «Построй веб-приложение с загрузкой PDF, выбором режима — с распознаванием текста или без — и выводом результата в виде текста и структурированных данных JSON». Модель сгенерировала код на TypeScript (расширенной версии JavaScript), а Уиллисон добавил автоматические тесты, применил методику разработки через тестирование (TDD) и разместил результат на бесплатном хостинге GitHub Pages. Исходный код полностью открыт, и любой желающий может убедиться, как всё устроено.
Ключевое архитектурное решение: файл никуда не отправляется. PDF обрабатывается локально, на устройстве пользователя. Никакого сервера, никакого стороннего хранилища. Для документов под грифами «коммерческая тайна» или «персональные данные» это не просто удобство, а принципиально иная модель безопасности: приватность становится не обещанием, а свойством архитектуры.
Почему браузерная обработка — это больше, чем технологический трюк
До недавнего времени браузер воспринимался как среда для отображения, а не для ресурсоёмких вычислений. Но PDF.js и Tesseract.js эту грань стёрли. Локальная обработка документов в браузере даёт три практических преимущества.
Первое — приватность по умолчанию. Если файл не покидает устройство, не нужно объяснять юристам, где и как обрабатываются данные, не требуется согласовывать внешнего обработчика, не возникает проблем с локализацией данных. Именно этот аргумент часто становится решающим при выборе архитектуры для внутренних инструментов компаний.
Второе — упрощение инфраструктуры. Не нужны очереди, серверы для обработки, регламенты удаления временных файлов. Для небольшой команды это означает возможность запустить нужный функционал без дополнительного бюджета на серверную часть.
Третье — предсказуемый пользовательский опыт (UX). Пользователь открыл страницу, загрузил PDF и получил результат без ожидания ответа внешнего API. Никаких сообщений «запрос обрабатывается, ожидайте».
Разумеется, у подхода есть ограничения. Тяжёлый многостраничный PDF со сложной графикой может нагрузить устройство пользователя. Для массового корпоративного сервиса такая модель подойдёт не всегда. Но для внутренних инструментов, B2B-порталов, плагинов к документообороту и систем, где требуется искать ответы по документам (RAG-систем), это вариант, который резко снижает порог внедрения.
Мини-кейс из практики
В одной компании внутренние документы регулярно поступали в виде PDF разного качества: часть с текстовым слоем, часть — сканы, часть — сложные многоколоночные отчёты. Сотрудники вручную копировали текст в рабочую систему. Попытка использовать облачный сервис распознавания была остановлена службой безопасности — документы нередко содержали конфиденциальные условия. После изучения архитектуры LiteParse команда интегрировала локальную обработку прямо в веб-интерфейс своей внутренней системы. Теперь при загрузке файла текст извлекается на компьютере пользователя, а в облако попадает уже обезличенный результат. Время обработки одного документа сократилось, а главное — исчез сам вопрос о том, где находятся данные. Это как раз тот случай, когда архитектурное решение снимает проблему, которую иначе пришлось бы решать бюрократически.
Чек-лист: что проверить, если вы идёте тем же путём
- Убедиться, что библиотеки PDF.js и Tesseract.js покрывают ваши сценарии. Большинство текстовых PDF обрабатываются PDF.js, но сложные сканы требуют оптического распознавания, а Tesseract работает в браузере не мгновенно.
- Определить режим: только текст, только распознавание или автоопределение. Автоматическое переключение между PDF.js и Tesseract.js упрощает интерфейс, но требует аккуратной обработки ошибок. Лучше дать пользователю выбор.
- Проверить производительность на мобильных устройствах. Тяжёлые PDF могут вызывать зависания. Полезно ввести ограничение на размер файла или показывать индикатор выполнения.
- Добавить понятные сообщения об ошибках. Если PDF зашифрован или повреждён, браузерный парсер должен сообщить пользователю, что пошло не так, а не молча «падать».
- Позаботиться о приватности. Даже если файл не уходит на сервер, результаты обработки могут содержать конфиденциальную информацию. Не стоит копировать их в сторонние сервисы без согласия пользователя.
- Использовать визуальные подсказки (Visual Citations). Если вы создаёте систему поиска по документам или просто показываете ответ, рамки вокруг исходного фрагмента PDF резко повышают доверие и позволяют быстро проверить правильность извлечения.
Вывод
LiteParse в браузере — не просто «ещё один PDF-парсер», а демонстрация того, как архитектурное решение меняет правила игры. Когда обработка документа происходит локально, приватность перестаёт быть обещанием в политике обработки данных и становится свойством системы. ИИ-ассистент Claude Code в этой истории выступил не как волшебная палочка, а как ускоритель для инженера, который точно знал, что он хочет построить: сначала план, потом сборка, потом проверка. Полезный ориентир: иногда лучший сервис — тот, где файл даже не покидает вкладку браузера.
Подписывайтесь на канал, чтобы не пропустить следующие разборы нестандартных архитектур и инженерных решений.
Вопрос в конце:
Готовы ли вы отказаться от серверной обработки PDF в пользу браузерной, если приватность станет архитектурным свойством, а не обещанием в пользовательском соглашении? Поделитесь опытом в комментариях.