How to Process Documents at Scale with LLMs – Hamel’s Blog - Hamel Husain
Хамел Хусейн пригласил Шрею Шанкар, AI-исследовательницу из UC Berkeley, в рамках курса LLM Evals, чтобы рассказать, как обрабатывать документы в больших масштабах с помощью LLM. Её работа находится на стыке AI-систем и человеко-компьютерного взаимодействия: она создала открытые инструменты docETL, DocWrangler и EvalGen, которые приняли на вооружение Snowflake, OpenAI и ChromaDB. docETL реализует «семантические операторы» (map, filter, reduce) для неструктурированного текста и оптимизатор запросов с директивами переписывания, который через декомпозицию задач и «каскады задач» снижает стоимость до 86%, оставаясь в пределах 90% целевой точности. DocWrangler — это IDE, построенная вокруг концепции «Трёх разрывов» (понимания, спецификации и обобщения), помогающая пользователям управлять AI. Проект EvalGen раскрывает ключевую идею «дрейфа критериев оценки»: понимание задачи пользователями меняется по мере просмотра примеров, и инструменты оценки должны это поддерживать.
Я пригласил Shreya Shankar, AI-исследовательницу из UC Berkeley, в рамках нашего курса LLM Evals. Работа Shreya находится на стыке AI-систем и человеко-компьютерного взаимодействия — двух областей, которые редко общаются друг с другом.
Традиционные системы данных оптимизировались под структурированные данные: строки, столбцы, SQL-запросы. Но теперь организации хотят извлекать инсайты из огромных хранилищ документов: PDF, Google Docs, тредов в Slack, внутренних вики. LLM могут читать эти данные и рассуждать о них. Вопрос в том, как делать это эффективно и точно в больших масштабах. Какие принципы из систем данных по-прежнему применимы? Какие новые абстракции нам нужны?
Именно над этими вопросами Shreya работает уже пять лет. Она создала открытые инструменты и алгоритмы, которые приняли на вооружение такие компании, как Snowflake, OpenAI и ChromaDB, а её идеи сформировали то, как индустрия мыслит о семантической обработке данных.
Что делает её исследования убедительными — это лежащая в их основе философия. В своём докладе об исследовательском и литературном программировании я доказывал, что лучшие инструменты разработчика помогают думать прямо во время написания кода. Они позволяют инспектировать промежуточные результаты, итеративно уточнять своё понимание и доводить намерения через прямое взаимодействие. Более ранняя работа Shreya, Operationalizing Machine Learning, документировала именно это напряжение: команды яростно спорят о ноутбуках против скриптов, потому что оптимизируют разные вещи. Одни хотят скорости; другие — надёжности.
DocWrangler, EvalGen и другие созданные ею инструменты разрешают это напряжение для обработки данных с помощью LLM. Они воплощают исследовательское программирование: вы запускаете пайплайны на выборках, инспектируете выводы рядом с исходным текстом, делаете заметки об ошибках, и система синтезирует ваш фидбэк в улучшенные промпты.
Ниже — версия её презентации с комментариями.
Презентация с комментариями
Проблемы неструктурированных данных
Системы данных — одна из величайших историй успеха в computing: пять десятилетий исследований породили индустрию на триллион долларов, и каждая компания на земле ими пользуется. Но они оптимизировались под структурированные данные. Аккуратные строки и столбцы.
Большая часть мировых данных не вписывается в эту форму. Они живут в судебных стенограммах, полицейских отчётах, новостных статьях и медицинских картах.
Пример от пользователей Shreya: аналитики данных в офисах государственных защитников, которые хотят лучше представлять интересы своих подзащитных. У каждого дела разнородные данные: судебные стенограммы (сотни страниц), полицейские отчёты, новостные статьи, даже изображения и видео. Аналитик хочет найти где-нибудь в материалах дела упоминания расовой предвзятости. Возможно, если предвзятость присутствует, они смогут добиваться более справедливого приговора.
Поиск расовой предвзятости требует рассуждения. Неявная или явная предвзятость субъективна, зависит от контекста и не поддаётся захвату регулярными выражениями. А запуск передовых LLM на каждом документе в больших масштабах стоил бы целое состояние.
LLM могут читать эти данные и рассуждать о них. Но наивное применение их к тысячам документов — это медленно, дорого и часто неточно. Нельзя просто направить мощную модель на гору PDF-файлов и ожидать хороших результатов.
Семантическая обработка данных
Традиционные базы данных используют операторы вроде SELECT, GROUP BY и JOIN над структурированными таблицами. Развивающаяся область семантической обработки данных применяет похожую идею к неструктурированному тексту, используя LLM для работы новых «семантических операторов».
На слайде показан пайплайн, который извлекает имена судей из судебных стенограмм, затем группирует по судье, чтобы обобщить паттерны предвзятости. Выходная схема задаётся явно: пользователь объявляет, какие атрибуты ему нужны, а LLM их заполняет. Пользователи не пишут процедурный код; они описывают нужный им результат.
Эта парадигма уже принимается на вооружение крупными базами данных, такими как Databricks, Google BigQuery и Snowflake, под названиями вроде AI SQL. Исследования Shreya сосредоточены на двух ключевых вопросах:
Масштабируемость: Как сделать эти семантические пайплайны быстрыми и дешёвыми? Управляемость: Как помочь пользователям контролировать AI, чтобы получать нужные результаты?
docETL: Создание масштабируемых пайплайнов
Открытая система Shreya, docETL, реализует семантические операторы для текста. Датасет в docETL — это коллекция документов (как список JSON-объектов).
docETL построен на трёх основных операторах:
1. Семантический Map: Применяет преобразование один-к-одному к каждому документу.
Число документов на входе равно числу на выходе. Каждый документ обогащается новыми атрибутами (statements, explanation), но размер коллекции остаётся прежним.
2. Семантический Filter: На слайде показано, как 10 000 документов сокращаются до 138 — снижение на 99% от одного предиката на естественном языке. Экономия затрат накапливается, потому что нижестоящие операторы обрабатывают только те 138, что прошли фильтр.
3. Семантический Reduce: Группирует документы по ключу и применяет агрегацию. На слайде показана группировка по имени судьи. Обратите внимание на вывод: 250 судей из 10 000 стенограмм. LLM должна синтезировать информацию из множества документов в единое резюме на каждую группу, и ограничения контекстного окна сдерживают то, сколько документов можно обработать вместе.
Сила приходит от композиции этих операторов. Фильтруй рано. Применяй map, чтобы извлечь структуру. Используй reduce для агрегации. Размещение дорогого map перед фильтром тратит вычисления на документы, которые вы всё равно отбросите.
Оптимизация семантических пайплайнов
Наивное выполнение такого пайплайна — запуск передовой LLM на каждом документе — было бы дорогим. Ключевой вклад docETL — это оптимизатор запросов, делающий эти пайплайны одновременно дешевле и точнее.
Он черпает вдохновение из традиционных оптимизаторов баз данных, но адаптирует их под нечёткую и дорогую природу LLM. Ключевая идея — директивы переписывания: правила преобразования пользовательского пайплайна в более эффективный, эквивалентный.
Переписывание ради точности: Декомпозиция задачи
LLM плохо справляются с длинными документами или сложными инструкциями. Один промпт, запрашивающий четыре разных атрибута из 100-страничного документа, может упустить некоторые из них. docETL повышает точность, разбивая проблему на части.
Декомпозиция данных (Split-Map-Reduce): Система разбивает документы на чанки перед обработкой. Размер чанка подбирается эмпирически: слишком маленький — теряется контекст; слишком большой — LLM упускает детали, спрятанные в середине. Шаг слияния требует тщательного проектирования, потому что чанки порождают перекрывающиеся или противоречащие извлечения. Если два чанка оба извлекают «Судья Смит сделал предвзятое заявление», операция reduce должна устранить дубликаты. Если они извлекают противоречивую информацию, она должна согласовать их или пометить конфликт.
Декомпозиция задачи: Вместо одного сложного промпта docETL может создать пайплайн из более простых промптов. Промпт, запрашивающий четыре атрибута, можно переписать в четыре отдельные операции map, каждая из которых извлекает по одному атрибуту, за которыми следует операция, объединяющая результаты.
Переписывание ради стоимости: Сокращение вызовов LLM
docETL также использует переписывания для снижения затрат:
Слияние операторов (Operator Fusion): Объединяет два простых, идущих подряд оператора в один вызов LLM. Синтез кода (Code Synthesis): Заменяет простой семантический оператор (например, конкатенацию списка результатов) на бесплатную Python-функцию.
Проталкивание проекции (Projection Pushdown): Если пайплайну нужны только небольшие части крупного документа, docETL может вставить начальный, дешёвый шаг (вроде поиска по ключевым словам или по эмбеддингам), чтобы извлечь только релевантные секции, резко сокращая объём текста, отправляемого дорогим нижестоящим LLM.
Чтобы придумать эти директивы переписывания, потребовалось изобрести новые типы операторов помимо базовых map/filter/reduce:
Оператор Gather: Когда вы разбиваете документы на чанки, отдельные чанки часто не имеют смысла в изоляции. Кто такой «он»? О каком контракте они говорят? Оператор Gather дополняет каждый чанк полезным контекстом: скользящим окном предыдущих чанков, резюме документа до этого места или метаданными вроде оглавления. Это позволяет LLM осмыслить каждый чанк во время переписываний split-map-reduce. Оператор Resolve: Разрешение сущностей как полноправный гражданин. Если вы хотите группировать по извлечённому LLM атрибуту (например, именам судей), LLM часто извлекает их непоследовательно: «Судья Смит», «Дж. Смит», «достопочтенный Смит». Оператор Resolve нормализует их перед группировкой, гарантируя, что все документы попадут в правильную группу.
Каскады задач: компромисс между стоимостью и точностью
Чтобы управлять компромиссом между стоимостью и точностью, docETL использует Каскады задач (Task Cascades) — обобщение каскадов моделей (классической техники, где дешёвые модели обрабатывают лёгкие случаи, а дорогие — сложные).
На слайде показан каскад для вопроса «Отменяет ли это заключение решение нижестоящего суда?». Вместо запуска GPT-4o на каждом документе система сначала задаёт более дешёвые вопросы: «Упоминается ли вообще нижестоящий суд?» и «Говорится ли о возврате дела на пересмотр?». Эти прокси отсеивают очевидные отрицательные случаи. До дорогого оракула доходят только неоднозначные случаи.
Каскад задач может варьировать три вещи: модель (дешёвая против дорогой), данные (резюме против полного текста) и саму задачу (более простой коррелирующий вопрос против настоящего вопроса). У большинства документов ответы очевидны: судебное заключение, которое никогда не упоминает нижестоящий суд, явно его не отменяет. Хорошо спроектированный каскад разрешает 80–90% случаев дешёвыми прокси-проверками, оставляя дорогие вызовы для по-настоящему неоднозначных входов.
Выстраивая оптимальную последовательность таких прокси-задач, docETL может снизить затраты до 86%, оставаясь в пределах 90% целевой точности.
Глобальный поиск лучшего плана
В отличие от традиционных баз данных, единого «лучшего» плана не существует. Оптимальный пайплайн зависит от бюджета пользователя и требований к точности. docETL использует алгоритм глобального поиска, вдохновлённый Monte Carlo Tree Search, чтобы исследовать пространство возможных переписываний.
Почему бы просто не оптимизировать каждый оператор независимо? Потому что операторы взаимодействуют. То, как вы выполняете оператор 3, зависит от реализаций, выбранных для операторов 1 и 2. Нижестоящие операторы могут исправлять, дополнять или интерпретировать результаты вышестоящих по-разному. Нужно рассматривать целые пайплайны, а не подвыражения.
Поиск рассматривает пайплайны как узлы графа. Каждое ребро — это переписывание. LLM-агент выбирает, какую директиву переписывания применить, читает примеры данных и создаёт новые промпты. Система использует отбор в духе UCB, чтобы приоритизировать переписывание тех пайплайнов, которые одновременно высококачественны и вероятно породят потомков на Парето-фронте.
На реальных рабочих нагрузках от государственных защитников и журналистов оптимизатор docETL каждый раз находит наиболее точный план запроса — часто вдвое точнее конкурирующих систем, таких как Lotus из Stanford или Polyest/Abacus из MIT. Он также превосходит агента на базе GPT-5, которому дали доступ к тому же движку запросов и документации. Агент может тестировать пайплайны на выборках и свободно итерировать, но тщательно спроектированные директивы переписывания всё равно побеждают.
Doc Wrangler: IDE для управления AI
Масштабируемой системы недостаточно, если пользователи не могут выразить то, что им нужно. Команда Shreya построила Doc Wrangler — интерактивную среду разработки (IDE) для создания пайплайнов docETL.
Дизайн направляется фреймворком под названием Три разрыва (Three Gulfs), который выделяет пробелы, с которыми сталкиваются пользователи при работе с AI над неструктурированными данными.
1. Разрыв понимания: Что в моих данных?
Пользователи часто не знают всего диапазона содержимого и краевых случаев в своих документах. Нельзя написать хорошие промпты для данных, которых не понимаешь.
Решение Doc Wrangler: Он предоставляет инспектор для просмотра выводов оператора бок о бок с исходным документом. Пользователи могут оставлять заметки и фидбэк по примерам — процесс, похожий на открытое кодирование (open coding) в качественном анализе.
Пример: медицинский аналитик обрабатывает стенограммы разговоров врача с пациентом, чтобы извлечь лекарства. Инспектируя выводы, он замечает кое-что: каждое упоминание лекарства сопровождается дозировкой. Он не знал этого, когда начинал. Теперь он понимает, что хочет извлекать ещё и дозировки. Или он видит появляющиеся безрецептурные препараты вроде Tylenol и решает, что ему нужны только рецептурные лекарства.
Эти заметки остаются на боковой панели. На практике пользователи накапливают 25–30 заметок, пока открыто кодируют свои данные, и накопленные заметки выявляют паттерны: «я постоянно помечаю безрецептурные препараты» превращается в осознание «мне нужны только рецептурные лекарства».
Находка из пользовательских исследований: люди изобретали собственные стратегии, чтобы перекрыть этот разрыв. Они писали «одноразовые пайплайны»: обобщи эти документы, извлеки ключевые идеи. Операции без аналитической цели. Просто способы узнать, что в данных, прежде чем приступать к настоящему анализу.
2. Разрыв спецификации: Как написать правильный промпт?
Пользователи накапливают десятки наблюдений о своих данных, но с трудом переводят их на язык промпта. «Только рецептурные лекарства» понятно человеку, но должно быть операционализировано: означает ли это исключить Tylenol? А как насчёт инсулина, который рецептурный, но в некоторых штатах также доступен без рецепта?
Решение Doc Wrangler: Он использует LLM, чтобы синтезировать заметки и фидбэк пользователя с шага понимания в предлагаемый, улучшенный промпт.
3. Разрыв обобщения: Будет ли это работать в масштабе?
Промпт, который работает на нескольких примерах, может провалиться на большем датасете, потому что стал слишком сложным, чтобы LLM могла надёжно ему следовать.
Решение Doc Wrangler: Он автоматически запускает LLM-судью на выборке выводов, чтобы обнаружить, когда многосоставная задача начинает давать сбои. Если он находит неточный компонент, он предлагает переписывание docETL, чтобы разложить сложную операцию на пайплайн из более простых и надёжных.
Финальный вызов: Оценка
Как понять, действительно ли ваш пайплайн работает? Для субъективных задач вроде «найти упоминания расовой предвзятости» нет заранее готовых меток. Это не как с кодом, где можно проверить, запускается ли он. Здесь нет эталонной истины (ground truth).
Этот вызов привёл к проекту EvalGen и ключевому инсайту: дрейф критериев оценки.
Когда пользователи начинают оценивать выводы LLM, их собственное понимание задачи эволюционирует. Они стартуют с простого рубрикатора, но по мере просмотра большего числа примеров уточняют его.
Пример: пользователи оценивали задачу извлечения сущностей на твитах. Одно правило: «Не извлекать хэштеги как сущности». Когда они видели извлечённые хэштеги, они помечали это как ошибку. Но когда раз за разом появлялся #ColinKaepernick (знаменитый футболист), некоторые пользователи передумали. «На самом деле это заметная сущность. Я рад, что её извлекли». Увидев это несколько раз, они уточнили правило: «Не извлекать хэштеги, если только они не представляют заметную сущность».
Стандартная ML-оценка предполагает фиксированные критерии: определить метрики заранее, собрать метки, измерить производительность. Но пользователи хотели добавлять новые критерии по мере обнаружения режимов сбоя и переинтерпретировать существующие критерии, чтобы лучше соответствовать поведению LLM. EvalGen это поддерживает: он запрашивает метки на выводах по мере их генерации, строит LLM-оценщиков, отражающих уточнённые критерии пользователя, и выдаёт «табели успеваемости», показывающие, насколько хорошо выводы соответствуют намерениям.
Shreya и я совместно разработали эти идеи для нашего курса LLM Evals. Эти идеи приняли на вооружение крупные LLM-ops компании, и они представлены в OpenAI cookbook.
Ключевые выводы
Обработка документов с помощью LLM — это больше, чем prompt engineering. Создание надёжных систем требует интеграции идей из баз данных, HCI и AI:
Структурируйте проблему: Используйте семантические операторы (map, filter, reduce), чтобы структурировать задачи обработки неструктурированных данных привычным, компонуемым образом. Оптимизируйте систему: Используйте оптимизатор запросов с директивами переписывания, чтобы автоматически преобразовывать пайплайны ради лучшей стоимости и точности. Техники вроде декомпозиции задач и каскадов задач незаменимы. Расширяйте возможности пользователя: Стройте интерактивные инструменты, которые помогают пользователям понимать свои данные, специфицировать свои намерения и справляться со сбоями в масштабе. Три разрыва дают полезный фреймворк для проектирования. Итерируйте над оценкой: Признайте, что сами критерии оценки будут эволюционировать. Постройте плотную петлю обратной связи, где вы непрерывно размечаете данные, анализируете сбои и уточняете своё определение успеха.
Сессия вопросов и ответов
Обобщается ли UX DocWrangler на другие AI-задачи? (Тайм-код: 56:50) Это была неожиданная находка. Изначально Shreya думала, что Три разрыва специфичны для обработки документов. Но AI-инженеры в пользовательских исследованиях сразу узнали этот паттерн. При программировании агентов вы сталкиваетесь с той же проблемой: агенты делают вызовы инструментов, демонстрируют пути рассуждений, ведут себя непредсказуемым образом. Вам нужны интерфейсы, чтобы инспектировать трейсы, оставлять фидбэк и итеративно уточнять. Разрыв понимания касается не только данных; он касается понимания любого поведения системы, которого вы не предвидели. Эта модель обобщается за пределы документов на любую сложную AI-систему. Почему это исследование так похоже на продукт? (Тайм-код: 01:00:10) Две причины. Во-первых, исследования систем данных по своей природе прикладные. Они решают проблемы индустрии на триллион долларов. Каждая статья включает создание систем, которыми люди могут пользоваться. Во-вторых, Shreya сочетает это с HCI, который требует строить пригодные интерфейсы для проверки теорий о человеко-AI коллаборации. Этот «двойной удар» порождает исследования, которые выглядят как питч-деки стартапов: работающее ПО, пользовательские интервью, анализ болевых точек, продуктовые сценарии. (Я регулярно шучу об этом со Shreya.) Но в душе она академик. Цель — открытие новых интерфейсных парадигм, а не построение компаний. Почему обработка данных не так хайпуется, как чат-боты? (Тайм-код: 01:03:36) Сообщество управления данными значительно меньше, чем сообщество AI/ML. Однако промышленная польза огромна. Есть гигантская возможность в обучении инженеров построению масштабируемых, семантических систем данных — именно на этом Shreya стремится сосредоточиться. Стоит ли использовать графы знаний (Knowledge Graphs) для этих задач? (Тайм-код: 01:07:10) Часто нет. Shreya постоянно сталкивается с этим вопросом, и ответ обычно в том, что люди усложняют себе жизнь, хватаясь за графы. Когда она спрашивает «зачем вам граф?», пользователи часто понимают, что им просто нужно было извлечь и сгруппировать сущности. Не все пары рёбер между всеми сущностями. Большинство рабочих нагрузок имеют ETL-характер: преобразовать данные, чтобы получить конкретные сущности или агрегации. Если конечная цель не в сложном обходе (поиск путей между разрозненными узлами), насильное втискивание данных в графовую структуру добавляет ненужное трение. Вы тратите время на загрузку данных в графовую базу только для того, чтобы затем понадобились инструменты вроде docETL, чтобы вытащить их обратно. Как вы справляетесь с многошаговым рассуждением (multi-hop) по страницам документа? (Тайм-код: 01:09:11) Это решается через оператор Gather. Вместо «прыжков» без разбора система обрабатывает чанки линейно, но дополняет их. Если чанк требует контекста со страницы 1 для понимания, оператор Gather извлекает этот контекст и прикрепляет его к чанку перед обработкой. Это фактически линеаризует зависимость рассуждения. Как оцениваются показатели уверенности (confidence scores) в Каскадах задач? (Тайм-код: 01:13:17) Уверенность выводится из логарифмов вероятностей генерации LLM, откалиброванных относительно модели-оракула (например, GPT-4o). Система перебирает пороговые значения на тестовой выборке, чтобы найти отсечку, которая поддерживает целевую точность относительно оракула.
👉 Хотите узнать больше об оценке LLM-пайплайнов? Загляните на наш курс AI Evals, который Shreya и я разработали совместно. Это живой когортный курс с практическими упражнениями и часами консультаций. Вот промокод на скидку 25% для читателей. 👈
Видео
Вот полное видео:
Слайды
Полная колода слайдов доступна здесь.