TuBrief
구독 채널
비디오
커뮤니티

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

TuBrief 편집팀
2026년 4월 22일
0
Computing/Software

원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.

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

관련 영상

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

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

Better Stack

커뮤니티의 다른 글

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

2026년 9월 13일

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

2026년 9월 13일

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

2026년 9월 13일

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

2026년 9월 13일

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

2026년 9월 12일

Apple Won the AI Race

2026년 9월 12일

댓글 (0)

Log in to leave a comment

아직 작성된 글이 없습니다

© 2026 . All rights reserved.

TuBrief
구독 채널
비디오
커뮤니티
로그인

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

Сокращение затрат на обслуживание за счет интеграции логики преобразования в 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 МБ выделяйте в отдельную очередь для обработки специализированными высокопроизводительными воркерами.

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