Они закрывают разные задачи и стоят в разных пайплайнах, не дублируют друг друга.
Docling — это парсер документов в первую очередь, OCR у него вторичен. Его сильная сторона — PDF/DOCX/PPTX/XLSX → Markdown с сохранением структуры таблиц, заголовков, списков. Для нативно-текстовых документов он почти не использует OCR — вытаскивает текстовый слой напрямую. OCR (через EasyOCR с cyrillic_g2) включается только когда страница оказывается отсканированной. Стоит в Dify-пайплайне, потому что в Dify нативно нет хорошего парсера документов.
RAGFlow cascade-OCR — это не один движок, а каскад из ONNX-моделей под Latin / Cyrillic / Chinese. Используется внутри RAGFlow для специализированных режимов чанкинга (naive / book / laws / paper), где важна именно скан-обработка с распознаванием layout. В апстриме RAGFlow до Hendrik-патча был только английский; ради кириллицы приходится держать его форк.
То есть Docling — для «чистых» документов с текстовым слоем (договоры, выгрузки), RAGFlow с cascade-OCR — для скан-PDF с layout-распознаванием. Решение, какой пайплайн использовать, остаётся за оператором: можно загружать в Dify (Docling) либо в RAGFlow напрямую.
Делали ли анализ существующих OCR-движков?
Да, проверяли несколько вариантов:
Tesseract — отбросили: медленный на скан-PDF и плохо держит таблицы.
EasyOCR — оставили, но только как backend внутри Docling для кириллицы (cyrillic_g2.pth).
MinerU 2.5-Pro — делали полноценный сравнительный замер с Docling. На реальном parallel-батче из 4 PDF Docling отработал за ~5 минут, MinerU — больше 12. Плюс AGPL-лицензия и отсутствие готового arm64-билда под GB10 — для нашей платформы это блокеры. Отказались.
Marker — оставили как теоретический fallback на случай, если попадётся клиент с критичными таблицами в скане. Пока не понадобился.
RAGFlow cascade-OCR (Hendrik fork) — взят целиком вместе с RAGFlow для скан-сценариев, потому что внутри уже есть мультиязычные ONNX-модели и интеграция с layout-detection.
Универсального «лучшего» движка нет — на текстовых PDF быстрее всего читать текстовый слой напрямую (что делает Docling), на сканах с таблицами выигрывает связка layout-detection + OCR (что делает RAGFlow).
Аналогичный вопрос по Dify: сравнивали с n8n и другими похожими продуктами?
Сравнивали. Они закрывают разные ниши, и формально это не конкуренты:
Dify — заточен под LLM-workflows: RAG, knowledge base, prompt-цепочки, агенты с инструментами, multi-step reasoning. Сильная сторона — abstraction над LLM-провайдерами, нативный chunker, knowledge-index ноды. Слабая — cron, webhooks, retry / error paths, интеграции с внешними системами через коннекторы.
n8n — заточен под интеграции: 400+ коннекторов, cron-триггеры, webhook-эндпоинты, retry-политики, error-routing. Слабая сторона — собственно LLM-логика (всё, что сложнее «вызови OpenAI», приходится писать руками в Code-нодах).
Langflow / Flowise — пробовали, по сути упрощённые Dify. Уступают в production-зрелости (плагины, sandbox, multi-tenant).
В AGmind сейчас стоит Dify, но n8n в бэклоге как опциональный compose-profile — для cron-задач и нестандартных интеграций, где Dify слабоват. Это не «или Dify или n8n», скорее «Dify для LLM-логики + n8n для оркестрации поверх».
Если задача из стартовой реплики — «законы → SQL» с HITL и OCR, то типичный layout получается такой: RAGFlow (cascade-OCR + laws chunker) → выгрузка структурированных полей в Postgres → Dify-workflow для запросов / валидации / HITL-аппрува. n8n в этом сценарии не обязателен, но удобен если документы прилетают по расписанию из внешних источников.
Они закрывают разные задачи и стоят в разных пайплайнах, не дублируют друг друга.
Docling — это парсер документов в первую очередь, OCR у него вторичен. Его сильная сторона — PDF/DOCX/PPTX/XLSX → Markdown с сохранением структуры таблиц, заголовков, списков. Для нативно-текстовых документов он почти не использует OCR — вытаскивает текстовый слой напрямую. OCR (через EasyOCR с cyrillic_g2) включается только когда страница оказывается отсканированной. Стоит в Dify-пайплайне, потому что в Dify нативно нет хорошего парсера документов.
RAGFlow cascade-OCR — это не один движок, а каскад из ONNX-моделей под Latin / Cyrillic / Chinese. Используется внутри RAGFlow для специализированных режимов чанкинга (
naive/book/laws/paper), где важна именно скан-обработка с распознаванием layout. В апстриме RAGFlow до Hendrik-патча был только английский; ради кириллицы приходится держать его форк.То есть Docling — для «чистых» документов с текстовым слоем (договоры, выгрузки), RAGFlow с cascade-OCR — для скан-PDF с layout-распознаванием. Решение, какой пайплайн использовать, остаётся за оператором: можно загружать в Dify (Docling) либо в RAGFlow напрямую.
Да, проверяли несколько вариантов:
Tesseract — отбросили: медленный на скан-PDF и плохо держит таблицы.
EasyOCR — оставили, но только как backend внутри Docling для кириллицы (
cyrillic_g2.pth).MinerU 2.5-Pro — делали полноценный сравнительный замер с Docling. На реальном parallel-батче из 4 PDF Docling отработал за ~5 минут, MinerU — больше 12. Плюс AGPL-лицензия и отсутствие готового arm64-билда под GB10 — для нашей платформы это блокеры. Отказались.
Marker — оставили как теоретический fallback на случай, если попадётся клиент с критичными таблицами в скане. Пока не понадобился.
RAGFlow cascade-OCR (Hendrik fork) — взят целиком вместе с RAGFlow для скан-сценариев, потому что внутри уже есть мультиязычные ONNX-модели и интеграция с layout-detection.
Универсального «лучшего» движка нет — на текстовых PDF быстрее всего читать текстовый слой напрямую (что делает Docling), на сканах с таблицами выигрывает связка layout-detection + OCR (что делает RAGFlow).
Сравнивали. Они закрывают разные ниши, и формально это не конкуренты:
Dify — заточен под LLM-workflows: RAG, knowledge base, prompt-цепочки, агенты с инструментами, multi-step reasoning. Сильная сторона — abstraction над LLM-провайдерами, нативный chunker, knowledge-index ноды. Слабая — cron, webhooks, retry / error paths, интеграции с внешними системами через коннекторы.
n8n — заточен под интеграции: 400+ коннекторов, cron-триггеры, webhook-эндпоинты, retry-политики, error-routing. Слабая сторона — собственно LLM-логика (всё, что сложнее «вызови OpenAI», приходится писать руками в Code-нодах).
Langflow / Flowise — пробовали, по сути упрощённые Dify. Уступают в production-зрелости (плагины, sandbox, multi-tenant).
В AGmind сейчас стоит Dify, но n8n в бэклоге как опциональный compose-profile — для cron-задач и нестандартных интеграций, где Dify слабоват. Это не «или Dify или n8n», скорее «Dify для LLM-логики + n8n для оркестрации поверх».
Если задача из стартовой реплики — «законы → SQL» с HITL и OCR, то типичный layout получается такой: RAGFlow (cascade-OCR +
lawschunker) → выгрузка структурированных полей в Postgres → Dify-workflow для запросов / валидации / HITL-аппрува. n8n в этом сценарии не обязателен, но удобен если документы прилетают по расписанию из внешних источников.gemma-4-26B-A4B-it на 3090 не потянет контекст 128к)
хорошо что вообще есть звонки )))