Если вы следите за тем, как компании внедряют ИИ в реальную работу, вы, вероятно, уже сталкивались с аббревиатурой RAG. Проще говоря, это подход, при котором языковая модель не просто генерирует ответ из того, что «помнит» по обучению, а сначала ищет релевантную информацию в документах, и только потом отвечает. Это такой умный поисковик, встроенный в ИИ-помощника.
Проблема в том, что на практике этот подход упирается в неожиданное узкое место, и не там, где его обычно ищут.
Где именно «ломается трубопровод»
Когда говорят об ИИ-системах, чаще всего обсуждают качество самой модели: насколько точно она отвечает, как хорошо рассуждает, не путает ли факты. Но в реальных корпоративных внедрениях бутылочным горлышком нередко оказывается более приземлённая вещь – подготовка документов.
Представьте: у организации есть тысячи PDF-файлов, Word-документов, таблиц, отсканированных страниц. Прежде чем модель сможет «читать» эти документы и отвечать на вопросы по ним, каждый файл нужно распарсить, очистить, разбить на смысловые фрагменты и превратить в числовые представления – так называемые эмбеддинги. Только после этого информация попадает в векторную базу данных, из которой модель и черпает контекст при каждом запросе.
Это звучит как технический нюанс, но на практике при обработке сотен тысяч документов именно этот этап может занимать часы или даже дни. И если данные постоянно обновляются, задержка становится системной проблемой.
Разделяй и властвуй: распределённая обработка как ответ
Red Hat совместно с Anyscale предлагает решение, основанное на распределённой обработке данных. Идея не нова в мире больших данных, но её применение к RAG-пайплайнам – шаг логичный и прагматичный.
Вместо того чтобы обрабатывать документы последовательно на одной машине, задача разбивается на параллельные потоки, которые выполняются одновременно на нескольких узлах кластера. Это примерно как если бы вместо одного человека, читающего стопку книг, к работе подключилась целая команда – каждый берёт свою часть, и общая скорость резко возрастает.
Технически это реализуется через Ray Data – фреймворк для распределённой обработки данных – в связке с Docling, инструментом для извлечения структурированной информации из разнородных документов: PDF, таблиц, изображений с текстом и других форматов.
Всё это разворачивается на базе Red Hat OpenShift AI – платформы, которая обеспечивает инфраструктурный слой: управление вычислительными ресурсами, хранилищем, GPU-ускорением и всем тем, что нужно для стабильной работы подобных систем в корпоративной среде.
Что именно умеет Docling
Docling – это не просто PDF-парсер. Инструмент умеет работать со сложной вёрсткой: распознавать таблицы, разделять колонки, обрабатывать заголовки и подписи, понимать иерархию документа. Это важно, потому что большинство корпоративных документов устроены совсем не как чистый линейный текст – там есть врезки, сноски, многоколоночная вёрстка, сканы с OCR-слоем.
Если парсер неправильно «прочитал» документ – перепутал порядок абзацев или потерял данные из таблицы – то и ответы модели по этому документу будут ненадёжными. Качество подготовки данных напрямую влияет на качество итогового RAG-решения.
Почему это важно именно сейчас
RAG активно входит в корпоративный ИИ-стек, и это уже не эксперименты, а рабочие внедрения. Организации хотят, чтобы их внутренние модели отвечали на вопросы по актуальной документации, договорам, регламентам, базам знаний. И чем быстрее новые данные попадают в систему, тем более живой и полезной она становится.
Узкое место на этапе обработки документов – это не теоретическая проблема, а то, с чем сталкиваются команды в реальных проектах. Решение через распределённую обработку выглядит естественным: оно масштабируется горизонтально (то есть можно просто добавить больше машин), не требует переписывать логику с нуля и вписывается в уже существующую инфраструктуру на базе OpenShift.
Отдельный плюс такого подхода – унификация. Вместо того чтобы собирать пайплайн из разрозненных инструментов, команда получает единую среду, где управление данными, вычислениями и моделью находится в одном месте. Это снижает операционную нагрузку и упрощает отладку, когда что-то идёт не так.
Что остаётся за кадром
Решение выглядит убедительно на уровне архитектуры, но несколько вопросов остаются открытыми. Насколько просто всё это настроить команде без глубокой экспертизы в распределённых системах? Как поведёт себя Docling с документами на языках, отличных от английского, особенно если они содержат специфическую вёрстку? Как система справляется с документами низкого качества – плохо отсканированными или с непоследовательной структурой?
Эти вопросы не ставят под сомнение ценность подхода, но они важны для тех, кто рассматривает подобное решение как основу рабочей системы, а не исследовательский прототип.
В целом – это честная и прагматичная попытка закрыть реальную проблему, которую индустрия немного недооценивала на фоне гонки за качеством самих моделей. Данные нужно не только хранить, но и уметь быстро и правильно готовить – и это, как выясняется, само по себе нетривиальная задача.
