Docling часто ставят в один ряд с веб-скрейперами, но это совсем не он. Это инструмент для конвертации документов от IBM Research — а теперь ещё и проект LF AI & Data Foundation — который берёт уже имеющиеся у вас файлы (PDF, DOCX, PPTX, XLSX, HTML, изображения) и преобразует их в Markdown или JSON. Его собственный слоган буквально звучит так: «Подготовьте свои документы для gen AI».
Так что это практический обзор конвертера, а не краулера. Всё ниже было измерено на одной машине только с CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), результаты получены скриптами, а ошибки зафиксированы как ошибки. Репозиторий огромный и обновляется ежедневно — 63 069 звёзд, 4 449 форков и пуш в тот же день, когда я забрал метаданные, — поэтому любую цифру по версии или числу проблем здесь воспринимайте как снимок на конкретный момент, а не как константу.
Что такое Docling на самом деле — и чем он не является
Базовая единица всего в Docling — это DoclingDocument: ты парсишь файл в эту структуру, а затем экспортируешь Markdown, HTML, DocTags или JSON без потерь. Код распространяется по лицензии MIT (у отдельных моделей лицензии могут отличаться), проект вырос из IBM Research Zurich, и на момент написания актуальный релиз — v2.112.0, опубликованный за два дня до моего теста.
Главная сильная сторона — обработка PDF и изображений. Это не строковый парсинг, а набор моделей машинного обучения: модель макета RT-DETR, модель структуры таблиц TableFormer, опциональная vision-language-модель и RapidOCR для сканов. Эти модели восстанавливают разметку страницы, порядок чтения и структуру таблиц. Именно это и стоит оценивать; HTML-страница в таком тесте этого никогда не покажет.
Есть одно важное различие, которое экономит неделю путаницы. Docling ничего не скачивает. Он не рендерит JavaScript, не пробивает антибот-защиту и не краулит сайты. Ты приносишь файл — он его понимает. За обход сайта отвечает другой инструмент, и это важно позже, когда возникает вопрос, заменяет ли Docling Firecrawl (нет — они дополняют друг друга, и я ещё объясню почему).
Первый запуск, о котором никто не предупреждает
pip install docling на Python 3.14.2 проходит без проблем. А потом ты смотришь на виртуальное окружение и видишь 1,3 ГБ. Docling тянет весь ML-стек как жёсткие зависимости, даже если ты собираешься конвертировать только HTML:
| Зависимость | Размер на диске (МиБ, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ встроенные модели) | 75,6 |
| docling_parse | 30 |
И это ещё до того, как ты обработаешь первый PDF. Настоящая боль начинается именно тогда, потому что именно в этот момент загружаются модели. На новом изолированном кэше HuggingFace первая конвертация PDF заняла около 224 секунд, и почти всё это — загрузка, а не вычисления. Модели layout и TableFormer занимают около 506 МиБ на диске (342 МиБ TableFormer + 164 МиБ layout, проверено через du), а RapidOCR скачивает около 40 МБ весов PP-OCRv4 в site-packages. Вторая конвертация того же файла? 0,55 секунды. Модели уже в кэше, плату ты вносишь один раз.
Одно число лучше игнорировать: coldstart-скрипт выводит model_download_mb = 1060.2. Не используй его как реальный размер. Оно получается из os.walk, который идёт по симлинкам, а кэш HuggingFace хранит каждый файл модели один раз в blobs/, а затем переоткрывает его как симлинк в snapshots/ — поэтому обход считает 14 файлов моделей дважды. Корректная, совпадающая с du, дедуплицированная оценка — около 506 МиБ (только blobs — 505,4 МиБ). Вывод для тех, кто бенчмаркит Docling: отдельно указывайте объём загрузки и отдельно — размер на диске, потому что это разные вещи.
Есть и второй нюанс, который кусает всех, кто собирает контейнер с Docling. Весы лежат в двух местах и загружаются по двум разным правилам. Модели layout и TableFormer соблюдают HF_HOME и скачиваются при первой конвертации PDF. А вот модели RapidOCR — нет: они попадают в …/site-packages/rapidocr/models/, полностью обходя вашу кэш-конфигурацию. Если ты заранее собираешь образ или работаешь в air-gapped-среде, нужно учитывать оба кэша, и никакой HF_HOME второй случай не перекроет.
Теперь справедливое замечание. В более ранних версиях проекта появился docling-slim — облегчённое ядро примерно на 50 МБ, которое позволяет ставить pip install docling-slim[format-html] для HTML без притягивания torch. Так что вес в 1,3 ГБ — реальность для стандартного метапакета docling, но теперь это можно обойти. Я тестировал именно стандартный пакет, потому что именно его даёт pip install docling, но избыточная тяжесть — это не нерешённый баг: модульное решение уже есть и отслеживается в issue #2393.
Во время настройки я наткнулся на маленькую, но неприятную проблему: import docling; docling.__version__ вызывает AttributeError: module 'docling' has no attribute '__version__'. Сам модуль версию не экспортирует. Рабочий способ — importlib.metadata.version("docling"), который возвращает '2.111.0'. Это мелкий DX-недочёт, в upstream висит с июля 2026 года как issue #3733.
Качество таблиц: где TableFormer действительно оправдывает себя
Таблицы — это основная причина, почему кто-то выбирает Docling вместо обычного PDF-to-text дампа, поэтому я сгенерировал семь PDF с таблицами и машинно-чётким эталоном, а потом сравнил результат ячейка за ячейкой. Здесь важны две метрики, и это не одно и то же: cell recall — доля эталонных значений, которые вообще попали в обнаруженную таблицу; in-row rate — доля, оказавшаяся в правильной строке. Смешивать их — значит приукрашивать инструмент, поэтому вот обе:
| Таблица (стресс-тест) | Обнаружена | Cell recall | In-row rate | Примечание |
|---|---|---|---|---|
| T1 обычная таблица с рамками (5×8), одна на странице | Нет | 0.0 | — | классифицирована как <!-- image -->, все ячейки потеряны |
| T2 без рамок (только линия под заголовком) | Да | 1.00 | 1.00 | идеально, точная сетка |
| T3 с объединённым двухуровневым colspan-заголовком | Да | 1.00 | 0.97 | все значения найдены; одно значение заголовка смещается на строку |
| T4 объединённая rowspan-метка строки, одна на странице | Нет | 0.0 | — | классифицирована как <!-- image --> |
| T5 colspan-заголовок + отсутствие рамок | Да | 1.00 | 0.97 | все значения найдены; тот же сдвиг строки заголовка, что и в T3 |
| T6 финансовая таблица, пустой столбец, выравнивание вправо | Да | 1.00 | 1.00 | пустой столбец сохранён, не сдвинут |
| T7 широкая сетка на 12 столбцов | Да | 1.00 | 1.00 | смещения столбцов нет, даже на широкой таблице |
Из пяти таблиц, которые Docling всё-таки обнаружил, все эталонные значения были сохранены — cell recall 1.00 у всех. В трёх из этих пяти каждое значение ещё и попало в свою правильную строку. В двух случаях с многоуровневым заголовком (T3 и T5) одно значение заголовка съезжает со своей строки, и in-row падает до 0,97 — данные все на месте, просто назначение строк немного плавает на составном заголовке.
Сложные структурные случаи оказались устойчивее, чем я ожидал. Двухуровневый colspan-заголовок корректно развернулся в GitHub-flavored Markdown (метка «Q1 2026» повторилась над двумя объединёнными столбцами — это правильный способ сворачивать colspan в GFM). Безрамочная сетка только с верхней линией заголовка (T2) прошла без искажений. Широкая таблица на 12 столбцов (T7) не сместилась. И полностью пустой финансовый столбец (T6) сохранился как пустые ячейки, а не был потерян или схлопнут. Это согласуется с официальными TEDS-оценками TableFormer — 95,4 для простых, 90,1 для сложных, 93,6 по всем таблицам, — которые в карточке модели заметно опережают Camelot (73,0) и EDD (88,3).
Но с объединёнными ячейками нужно быть осторожным: есть открытая проблема, которая говорит об обратном. Issue #3698 сообщает, что V1 и V2 некорректно обрабатывают объединения строк и столбцов. В моих тестовых файлах простые colspan (T3/T5) и rowspan были развёрнуты правильно, если не считать упомянутого сдвига строки в многоуровневом заголовке. Но проблемные кейсы из #3698 — это нерегулярные объединения на несколько строк и столбцов, а также многостраничные таблицы — уже патологический край. У меня был простой край. Поэтому точная формулировка узкая: простые colspan и rowspan здесь восстановились (многоуровневые заголовки могут сдвинуть строку); сложные и нерегулярные объединения по-прежнему остаются известной открытой проблемой. Не «объединённые ячейки работают», и не «объединённые ячейки сломаны».
Подводный камень: таблица на пустой странице может исчезнуть
Посмотрите ещё раз на таблицу — T1 и T4 вообще не были обнаружены. Docling вывел <!-- image --> и потерял все ячейки без ошибки. T1 — это совершенно обычная таблица 5×8 с рамками. Это достаточно тревожно, чтобы я не стал называть это просто слабостью парсинга таблиц, пока не выяснил, что именно вызывает проблему, поэтому я сделал скриптовый A/B-тест.
Сначала я исключил очевидные объяснения. Текстовый слой цел: pypdfium2 читает 327 символов из T1 и 221 из T4, значит это настоящие цифровые PDF, а не сканы. Отключение OCR (do_ocr=False) не помогает: таблицы всё равно исчезают. Если смотреть на DoclingDocument напрямую, видно len(doc.tables) == 0, тогда как len(doc.pictures) == 1 — модель макета классифицировала всю область таблицы как Picture.
Потом был решающий тест. Я заново отрендерил те же таблицы T1 и T4, но на этот раз окружил их несколькими обычными абзацами текста и снова прогнал через конвертацию. Оба случая прошли идеально: len(doc.tables) == 1, корректно были выведены таблицы в GFM, а у T4b метка rowspan «North» правильно повторилась по трём строкам. Та же таблица. Изменилось только одно: была ли она одна на почти пустой странице или встроена в текст.
Так что реальная оговорка не в том, что TableFormer хрупкий, а в том, что модель макета RT-DETR в Docling использует контекст страницы, и маленькая таблица, стоящая одна на почти пустой странице, вполне может быть прочитана как Picture и тихо отброшена. На практике это встречается очень легко: именно так выглядят инвойсы, спецификации и обрезанные экспорты — одна таблица на страницу, без соседнего текста. Решение скучное, но рабочее: дай модели макета контекст страницы или после конвертации проверь doc.tables и пометь страницы, где количество равно нулю. Это близко к issue #3495 (таблица, распознанная и как Table, и как Picture), но именно триггер пустой страницы — та же таблица исчезает в изоляции и конвертируется при наличии текста вокруг — я не нашёл опубликованным. Замерено, ранее не описано; не «баг, о котором никто не знал».
OCR на реальных сканах: RapidOCR, а не EasyOCR
Сканированные PDF — это место, где многие конвертеры тихо проваливаются, поэтому я дал Docling два настоящих скана с измеренным текстовым слоем из 0 символов — pypdfium2 показывает ноль восстанавливаемых символов, так что любой результат — это OCR, а не скрытый текстовый слой.
Одностраничный ocr_test.pdf вернулся чисто за 14,3 секунды на CPU: «Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package» был восстановлен дословно. Четырёхстраничный nemotron_multipage.pdf запустил OCR на всех четырёх страницах и суммарно отработал за 70,1 секунды (17,5 с/страница), выводя повторяющееся тестовое предложение на каждой странице. OCR по умолчанию сработал автоматически — без флага, без конфигурации.
Вот деталь, в которой многие обзоры ошибаются: движок OCR по умолчанию — RapidOCR, а не EasyOCR. Я подтвердил это, наблюдая загрузку весов PP-OCRv4 .pth при первом запуске. Во многих старых статьях и даже в прежних FAQ по Docling до сих пор пишут, что по умолчанию используется EasyOCR; это устарело. Сейчас EasyOCR — это дополнительная опция, которую нужно включать отдельно. Ограничение остаётся прежним: OCR — это медленный путь при масштабе, и все приведённые здесь цифры — потолок для CPU; на GPU время было бы заметно ниже.
Реальные PDF, порядок чтения и время на страницу
Синтетические тесты доказывают отдельные поведения, а реальные PDF — что всё действительно работает. Я прогнал две born-digital статьи: 9-страничный технический отчёт Docling и 15-страничную статью «Attention Is All You Need», обе в двухколоночной верстке с таблицами и формулами.
В 15-страничной статье Attention все пять маркеров разделов — Abstract, Introduction, Background, Conclusion, References — появляются в порядке документа в линейризованном Markdown, несмотря на двухколоночную структуру. Все ключевые запросы по содержимому (Transformer, encoder, BLEU, multi-head) присутствуют, а знаменитые многоколонные таблицы результатов распознаются как четыре таблицы. Это настоящее восстановление порядка чтения и объединения колонок, а именно в этом и состоит основная ценность для RAG-чункования — нельзя нормально порезать документ, если линейризатор превращает двухколоночную страницу в кашу.
Время даёт неожиданный вывод. Время на страницу зависит от того, сколько структуры на каждой странице, а не от общего числа страниц. Более плотный 9-страничный отчёт работал со скоростью 14,95 секунды на страницу — медленнее, чем 15-страничная статья с 5,99 секунды на страницу — потому что в нём больше таблиц и фигур, а каждая из них запускает дополнительные inference-проходы layout и TableFormer. Так что «секунды на страницу» на CPU — это функция структурной плотности, а не длины документа. И снова: это один CPU-only прогон; это потолок, а не продакшн-цифра.
Мультиформатность и претензия на JSON без потерь
Docling рекламирует единый парсинг для разных форматов, поэтому я сгенерировал DOCX, XLSX и PPTX с известным содержимым и контрольными значениями, а потом проверил две вещи: появляются ли эти значения в Markdown и сохраняются ли они после JSON-цикла через export_to_dict().
| Файл | Время конвертации, с | Найдено в MD | Таблицы в MD | Сохраняется в JSON |
|---|---|---|---|---|
report.docx (заголовки + объединённая таблица "Total" + списки) | 0,137 | 7/7 | 1 | Да |
workbook.xlsx (2 листа, пустой столбец) | 0,016 | 6/6 | 2 | Да |
deck.pptx (3 слайда, списки + таблица) | 0,038 | 6/6 | 1 | Да |
Все контрольные значения попали в Markdown, таблицы были восстановлены (включая объединённую строку "Total" в DOCX и оба листа XLSX), и каждый probe также сохранился в JSON после export_to_dict() — именно это и подтверждает претензию на lossless-DoclingDocument, по крайней мере на чистых входных данных. Эти форматы проходят через нативные backend’ы, а не через ML-модели, поэтому они обрабатываются за десятки миллисекунд и работают полностью офлайн. Охват честный: по одному чистому файлу на формат — это доказательство широты, а не стресс-тест патологических Office-файлов.
HTML: точно, но не чисто
Это оговорка, от которой зависит, попадёт ли Docling в ваш RAG-пайплайн, так что читайте внимательно. Docling конвертирует весь HTML-документ. Он не делает main-content extraction в стиле readability. Я измерил, сколько сайтского интерфейса остаётся, подсчитав строки навигации, оглавления, cookie и футера в собственном выводе Docling.
| Страница | Непустых строк MD | Строк с boilerplate | % boilerplate | С какой строки начинается статья |
|---|---|---|---|---|
| Wikipedia "Web scraping" | 255 | 34 | 13.3% | 28 |
| scrapethissite/forms | 63 | 1 | 1.6% | — |
| books.toscrape | 65 | 0 | 0.0% | — |
| quotes.toscrape | 35 | 0 | 0.0% | — |
На странице с тяжёлым интерфейсом, как Wikipedia, около 13% строк Markdown — это навигация, оглавление и футер, а сама статья начинается только с 28-й строки: вывод стартует с «move to sidebar / Contents / Toggle the table of contents» и заканчивается «CS1 maint… / Search Wikipedia». На чистых контентных страницах (books, quotes) показатель близок к 0%, так что это проблема шаблонного интерфейса, а не плата за каждую страницу. Docling даёт достоверный Markdown всего документа, а не чистое извлечение основной статьи. В upstream проблема HTML-мебели отслеживается в issue #1865 (закрыт) и #1930 (открыт).
Чтобы оценка была честной, важно два момента. Во‑первых, именно для HTML Docling вообще не использует ML-модели — там работает backend BeautifulSoup на простом пайплайне. История про «vision-модели, читающие вашу страницу» относится только к PDF и изображениям; если дать Docling HTML, никакая логика layout или TableFormer не запускается. Во‑вторых, PDF-путь всё же пытается классифицировать header/footer-мебель, так что утверждение «boilerplate вообще не удаляется» было бы слишком сильным — именно HTML-backend возвращает вам весь интерфейс страницы.
Как он смотрится на фоне других решений — и где здесь Thunderbit
Попробовать Thunderbit для извлечения веб-данных
Главный инструмент, с которым Docling сравнивают, — это Firecrawl, так что вот таблица позиционирования. Сразу важная оговорка: это сравнение на уровне документации, а не бенчмарк на одной и той же машине. Firecrawl я на этих файлах не запускал. Здесь измерен только Docling; колонка Firecrawl взята из публичной документации.
| Ось сравнения | Firecrawl (по документации) | Docling (измерено здесь) |
|---|---|---|
| Основная задача | Краулинг и скрейпинг живого веба → Markdown | Конвертация уже имеющегося документа → Markdown/JSON |
| Загрузка / рендер JS / антибот | Да (hosted browser) | Нет — ты сам передаёшь файл |
| Извлечение основного контента | Да | Нет — честный полный документ (~13% boilerplate на Wikipedia) |
| Структура таблиц в PDF (ML) | ограниченно | Да — TableFormer (официальный TEDS 93,6; cell recall 1.00, in-row 0.97–1.00 на обнаруженных тестах) |
| Сканированный PDF / OCR | ограниченно | Да — RapidOCR по умолчанию (восстановлен скан без текстового слоя) |
| Ширина форматов | веб-страницы | PDF/DOCX/PPTX/XLSX/HTML/EPUB/изображения |
| Развёртывание | hosted API (+ self-host) | локальная pip-библиотека, офлайн, без API-ключа |
| Вес установки | API-ключ / лёгкий клиент | 1,3 ГБ стандартная установка + ~506 МиБ моделей (или docling-slim) |
| Лицензия | коммерческая / source-available | MIT |
Если в одной строке: Firecrawl — это ваш инструмент, когда данные лежат в живом интернете и их нужно краулить, рендерить JS и очищать от лишнего контента. Docling нужен тогда, когда документ уже у тебя есть — особенно PDF, сканы и Office-файлы с таблицами — и тебе нужна честная, офлайн-конвертация с сохранением структуры, реальным пониманием таблиц и OCR. Они дополняют друг друга. Реальный пайплайн краулит одним инструментом, а документы конвертирует другим.
И здесь я прямо скажу про Thunderbit, потому что я работаю здесь, и было бы странно делать вид, что это не так. Thunderbit и Docling не делают одну и ту же работу, и я не буду насильно приравнивать их друг к другу. Для разработчиков Thunderbit — это AI scraping API плюс MCP-сервер плюс CLI, а единица работы у него — живая веб-страница: POST /distill превращает URL в чистый Markdown, готовый для LLM (обрабатывая JS-рендеринг, антибот и CAPTCHA, которых Docling явно не касается), а POST /extract возвращает структурированный JSON, совпадающий со схемой, которую вы задаёте через JSON Schema. Это часть пайплайна «забрать и очистить» для RAG. Docling — это этап локального документа: PDF, скан, таблица, уже лежащие у тебя на диске. Если твой корпус — это веб-страницы, бери Thunderbit API, MCP-инструменты (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) или CLI (npx @thunderbit/thunderbit-cli). Если это PDF и сканы — бери Docling. Если и то и другое, а в реальных пайплайнах так бывает чаще всего, — используй оба, и ни один не пытается быть другим.
Вердикт: предварительный, с домашкой, которая ещё осталась
Я не буду давать одну общую оценку от 0 до 100, потому что взвешенный итог здесь смешал бы штрафы за то, что Docling никогда не обещал делать (например, краулинг), и делал бы вид, что это сравнимо. По отдельным направлениям на тех тестах, что я прогнал:
- Настройка / первый запуск: тяжело — окружение 1,3 ГБ, ~506 МиБ моделей, ~224 с на первый PDF, ~0,55 с на повторный — но
docling-slimпозволяет уйти от этой тяжести. - Качество таблиц: сильное, когда таблица обнаружена (cell recall 1.00 на 5/5, in-row 0.97–1.00), что совпадает с официальной историей TEDS на этих тестах.
- Надёжность обнаружения таблиц: ловушка пустой страницы — изолированная таблица может исчезнуть как Picture. Проверяй
doc.tablesпосле конвертации. - Сканированные PDF / OCR: работает, RapidOCR по умолчанию; на масштабе медленно.
- Мультиформатность: уверенно, JSON-цикл без потерь сохраняется.
- HTML: честно, но не чисто — без извлечения основного контента.
- DX для разработчика: аккуратный API на 3 строки и понятный
DoclingDocument, если не считать отсутствующий__version__.
Кому это нужно: командам, строящим RAG- или data-пайплайны поверх PDF, сканов и Office-файлов, которым нужна офлайн-конвертация с сохранением структуры и реальное понимание таблиц и OCR. Кому это не нужно: тем, кому нужен живой веб-краулинг или чистое извлечение основной статьи из HTML — это уже другой инструмент.
И поскольку это обзор, а не пресс-релиз, ограничения остаются на месте. Это целевой прогон — 7 синтетических таблиц и 2 реальных PDF на одной машине только с CPU — а не бенчмарк уровня TEDS. Несколько вещей я не тестировал, а вам стоит проверить до того, как делать Docling опорой пайплайна: опциональный путь VLM (GraniteDocling), реальный размер docling-slim, любой запуск на GPU, сложные и нерегулярные объединённые ячейки плюс многостраничные таблицы, точность формул при переводе в LaTeX и — самое неожиданное в продакшене — устойчивость к росту памяти на батчах, масштабированию через thread/GIL и жизненному циклу объектов на тысячах конвертаций. Docling силён в том, что обещает, и это подтверждается измерениями, а не маркетингом, но у него есть реальные границы, которые стоит понять заранее, прежде чем доверять ему корпус. Знайте про ловушку пустой страницы, закладывайте время на первую загрузку и проверьте поведение на своём масштабе сами.
Попробовать Thunderbit для извлечения веб-данных Get Started Free
Часто задаваемые вопросы
Docling — это веб-скрейпер или краулер? Нет. Docling преобразует уже имеющиеся у тебя документы — PDF, DOCX, PPTX, XLSX, HTML, изображения — в Markdown или JSON. Он не получает URL, не рендерит JavaScript и не обходит антибот-защиту. Краулинг живого веба — это отдельная задача, которую решают такие инструменты, как Firecrawl или веб-API Thunderbit; Docling начинает с файла, который ты ему передаёшь.
Насколько большой у Docling установочный размер и первый скачиваемый объём?
Стандартный метапакет docling создаёт окружение примерно на 1,3 ГБ, потому что подтягивает весь ML-стек как жёсткие зависимости (один только torch — 536 МиБ). Первая конвертация PDF скачивает примерно 506 МиБ моделей layout и TableFormer на диск плюс около 40 МБ весов RapidOCR и занимает около 224 секунд — почти всё это время уходит на загрузку. Вторая конвертация длится примерно 0,55 секунды. Если тебе нужны только лёгкие форматы, docling-slim (~50 МБ ядра) позволяет не идти по тяжёлому пути.
Есть ли в Docling OCR, и какой именно движок используется? Да. На отсканированном PDF без текстового слоя OCR Docling запускается автоматически и в моём тесте восстановил текст без проблем. Движок по умолчанию — RapidOCR, а не EasyOCR, что часто путают в старых обзорах. EasyOCR сейчас нужно подключать отдельно. OCR — медленная часть при масштабе, особенно на CPU.
Почему Docling превратил мою таблицу в изображение или вообще её потерял?
Скорее всего, сработал эффект пустой страницы. Модель макета RT-DETR в Docling использует контекст страницы, и маленькая таблица, стоящая одна на почти пустой странице, может быть классифицирована как Picture и исчезнуть без ошибки. Та же таблица в окружении обычного текста конвертируется нормально. Решение: либо давать модели контекст страницы, либо после конвертации проверять doc.tables и отмечать страницы, где их количество равно нулю.
Docling против Firecrawl — что выбрать? Это разные задачи, так что обычно не «или-или». Firecrawl краулит живой веб, рендерит JavaScript и извлекает основной контент. Docling конвертирует уже имеющиеся документы, умеет реально понимать таблицы в PDF и OCR и работает полностью офлайн. Если источник — веб-страницы, используй веб-инструмент (Firecrawl или API/MCP/CLI Thunderbit). Если это PDF, сканы или Office-файлы, бери Docling. В большинстве реальных пайплайнов используются оба.
