TuBrief
Subscribed Channels
Videos
Community

Модернизация конвейера обработки устаревших документов и сокращение затрат

TuBrief Editorial
April 22, 2026
0
Computing/Software

Written with AI assistance from the source video. The video is the authority.

Русский한국어EspañolEnglish中文हिन्दीالعربيةDeutschFrançaisPortuguêsBahasa Indonesia日本語

Related Video

Хватит строить RAG-пайплайны таким образом... Используйте MarkItDown6:17

Хватит строить RAG-пайплайны таким образом... Используйте MarkItDown

Better Stack

More from the community

사내 시스템에 llm api 붙일 때 마주하는 현실적인 한계와 대응법

September 13, 2026

레거시 백엔드에 GPT-6 Astra 붙일 때 예산 승인과 보안 통과를 먼저 끝내는 법이 있습니다

September 13, 2026

에이전트끼리 대화하다 6천만 원 청구서가 나오는 이유

September 13, 2026

사내 RAG 벡터 검색에 Okta 권한 필터를 직접 거는 방법

September 13, 2026

브라우저 에이전트에게 내 구글 계정을 통째로 넘기면 안 되는 이유

September 12, 2026

Apple Won the AI Race

September 12, 2026

Comments (0)

Log in to leave a comment

No posts yet

© 2026 . All rights reserved.

TuBrief
Subscribed Channels
Videos
Community
Log in

Модернизация конвейера обработки устаревших документов и сокращение затрат

Сокращение затрат на обслуживание за счет интеграции логики преобразования в Markdown

Если вы каждую неделю тратите по 5 часов на сверхурочную работу, пытаясь «запихнуть» сотни PDF, PPT и Excel файлов в RAG-систему, причина кроется в фрагментированных библиотеках для парсинга. Старая структура, смешивающая PyPDF2 и openpyxl, лишь увеличивает сложность кода. Внедрение библиотеки MarkItDown от Microsoft позволяет избавиться от запутанной логики ветвления.

При рефакторинге конвейера используйте паттерн «Фабрика процессоров»:

  1. Избавьтесь от библиотек, разбросанных по разным форматам, и унифицируйте интерфейс вызова с помощью функции convert() из MarkItDown.
  2. Разветвляйте способ обработки в зависимости от сложности документа. Для простых текстов выбирайте легкие парсеры, а для сложных документов с большим количеством таблиц — MarkItDown.
  3. Изолируйте все зависимости в Docker-контейнерах (Python 3.11 или выше) и развертывайте их с помощью FastAPI.

Эта структура позволяет независимо масштабировать движок парсинга. Сохранение структуры таблиц позволяет снизить ошибки при чтении документов LLM на 34% (согласно данным презентации Microsoft 2024 года).

Экономия 30% затрат на API за счет предварительной обработки Markdown

Стоимость токенов эмбеддингов напрямую пропорциональна длине Markdown-файла. Результаты, полученные с помощью MarkItDown, часто содержат метаданные или «шум», которые вовсе не обязательно отправлять в LLM. Только за счет фильтрации этого лишнего контента можно сократить расходы на API на 30%.

Постройте эффективную логику фильтрации:

  1. Используйте модуль re в Python, чтобы сократить последовательные переносы строк (\n{3,}) до двух, а также с помощью регулярных выражений удаляйте повторяющиеся нижние колонтитулы с информацией об авторских правах или HTML-теги.
  2. Используйте MarkdownHeaderTextSplitter для разбиения документа на части (чанки) по заголовкам. Раздельное управление дочерними чанками для поиска и родительскими чанками для контекста повышает точность поиска.
  3. Используйте MD5-хеширование, чтобы исключить дублирование эмбеддингов для одних и тех же отчетов на уровне источника.

Оптимизация использования токенов позволяет заметно снизить ежемесячные затраты на корпоративные API.

Управление качеством данных с помощью Snapshot-тестирования

При изменении версий библиотек результаты парсинга могут незначительно меняться. Прекратите заниматься ручной проверкой, открывая каждый файл самостоятельно. Внедрение snapshot-тестирования позволит мгновенно выявлять деградацию качества.

Создайте среду модульного тестирования для предотвращения регрессий:

  1. Установите плагин pytest-regressions и сохраните корректно преобразованные файлы Markdown в качестве «эталонных» (golden master).
  2. Настройте тестовый скрипт так, чтобы он каждый раз сравнивал результат преобразования с эталоном. При возникновении различий (diff) немедленно отправляйте уведомление.
  3. Используйте модель sentence-transformers для измерения косинусного сходства между оригиналом и преобразованным файлом. Можно настроить логирование только в тех случаях, когда коэффициент сохранения формата ниже 0.9.

Эта система автоматизации избавит вас от ручной сверки, которая отнимала по 5 часов каждую неделю.

Ускорение пакетной обработки за счет параллелизации

Последовательная обработка тысяч документов — это неэффективное использование системы. Если использовать concurrent.futures.ProcessPoolExecutor для параллелизации пакетной обработки, задачи, занимавшие несколько дней, можно завершить за несколько часов.

Реализуйте архитектуру параллелизации следующим образом:

  1. Если на сервере 16 ГБ оперативной памяти, ограничьте количество воркеров до 20–25. Чрезмерное увеличение приведет лишь к ошибкам памяти (Out of Memory).
  2. Разбивайте файлы на пакеты по 50–100 штук и принудительно вызывайте сборщик мусора (garbage collection) после каждого пакета, чтобы избежать утечек памяти.
  3. Крупногабаритные PDF-файлы размером более 10 МБ выделяйте в отдельную очередь для обработки специализированными высокопроизводительными воркерами.

Этот подход помогает поддерживать актуальность данных, эффективно используя системные ресурсы.