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 раскрывает ключевую идею «дрейфа критериев оценки»: понимание задачи пользователями меняется по мере просмотра примеров, и инструменты оценки должны это поддерживать.
I hosted Shreya Shankar, AI researcher at UC Berkeley, as part of our LLM Evals course. Shreya’s work sits at the intersection of AI Systems and Human-Computer Interaction, two fields that rarely talk to each other.
Я пригласил Shreya Shankar, AI-исследовательницу из UC Berkeley, в рамках нашего курса LLM Evals. Работа Shreya находится на стыке AI-систем и человеко-компьютерного взаимодействия — двух областей, которые редко общаются друг с другом.
Traditional data systems have been optimized for structured data: rows, columns, SQL queries. But organizations now want to extract insights from vast document stores: PDFs, Google Docs, Slack threads, internal wikis. LLMs can read and reason about this data. The question is how to do it efficiently and accurately at scale. What principles from data systems still apply? What new abstractions do we need?
Традиционные системы данных оптимизировались под структурированные данные: строки, столбцы, SQL-запросы. Но теперь организации хотят извлекать инсайты из огромных хранилищ документов: PDF, Google Docs, тредов в Slack, внутренних вики. LLM могут читать эти данные и рассуждать о них. Вопрос в том, как делать это эффективно и точно в больших масштабах. Какие принципы из систем данных по-прежнему применимы? Какие новые абстракции нам нужны?
These are the questions Shreya has spent five years researching. She’s built open-source tools and algorithms that have been adopted by companies like Snowflake, OpenAI, and ChromaDB, and her ideas have shaped how the industry thinks about semantic data processing.
Именно над этими вопросами Shreya работает уже пять лет. Она создала открытые инструменты и алгоритмы, которые приняли на вооружение такие компании, как Snowflake, OpenAI и ChromaDB, а её идеи сформировали то, как индустрия мыслит о семантической обработке данных.
What makes her research compelling is the underlying philosophy. In my talk on exploratory and literate programming, I argued that the best developer tools help you think while you code. They let you inspect intermediate results, iterate on your understanding, and refine your intent through direct manipulation. Shreya’s earlier work, Operationalizing Machine Learning, documented exactly this tension: teams disagree violently about notebooks vs. scripts because they’re optimizing for different things. Some want velocity; others want reliability.
Что делает её исследования убедительными — это лежащая в их основе философия. В своём докладе об исследовательском и литературном программировании я доказывал, что лучшие инструменты разработчика помогают думать прямо во время написания кода. Они позволяют инспектировать промежуточные результаты, итеративно уточнять своё понимание и доводить намерения через прямое взаимодействие. Более ранняя работа Shreya, Operationalizing Machine Learning, документировала именно это напряжение: команды яростно спорят о ноутбуках против скриптов, потому что оптимизируют разные вещи. Одни хотят скорости; другие — надёжности.
DocWrangler, EvalGen, and other tools she’s built resolve this tension for LLM-powered data processing. It embodies exploratory programming: you run pipelines on samples, inspect outputs alongside source text, take notes on errors, and have the system synthesize your feedback into improved prompts.
DocWrangler, EvalGen и другие созданные ею инструменты разрешают это напряжение для обработки данных с помощью LLM. Они воплощают исследовательское программирование: вы запускаете пайплайны на выборках, инспектируете выводы рядом с исходным текстом, делаете заметки об ошибках, и система синтезирует ваш фидбэк в улучшенные промпты.
Below is an annotated version of her presentation.
Ниже — версия её презентации с комментариями.
Annotated Presentation
Презентация с комментариями
Unstructured Data Challenges
Проблемы неструктурированных данных
Data systems are one of computing’s greatest success stories: five decades of research have produced a trillion-dollar industry, and every company on earth uses them. But they’ve been optimized for structured data. Neat rows and columns.
Системы данных — одна из величайших историй успеха в computing: пять десятилетий исследований породили индустрию на триллион долларов, и каждая компания на земле ими пользуется. Но они оптимизировались под структурированные данные. Аккуратные строки и столбцы.
Most of the world’s data doesn’t fit that mold. It lives in court transcripts, police reports, news articles, and medical records.
Большая часть мировых данных не вписывается в эту форму. Они живут в судебных стенограммах, полицейских отчётах, новостных статьях и медицинских картах.
(An example from Shreya’s users: public defender data analysts who want to help represent their defendants better. Each case has heterogeneous data: court transcripts (hundreds of pages), police reports, news articles, even images and videos. The analyst wants to find mentions of racial bias somewhere in the case. Maybe if bias is present, they can argue for a more just sentence.
Пример от пользователей Shreya: аналитики данных в офисах государственных защитников, которые хотят лучше представлять интересы своих подзащитных. У каждого дела разнородные данные: судебные стенограммы (сотни страниц), полицейские отчёты, новостные статьи, даже изображения и видео. Аналитик хочет найти где-нибудь в материалах дела упоминания расовой предвзятости. Возможно, если предвзятость присутствует, они смогут добиваться более справедливого приговора.
Finding racial bias requires reasoning. Implicit or explicit bias is subjective, context-dependent, and impossible to capture with regular expressions. And running state-of-the-art LLMs on every document at scale would cost a fortune.
Поиск расовой предвзятости требует рассуждения. Неявная или явная предвзятость субъективна, зависит от контекста и не поддаётся захвату регулярными выражениями. А запуск передовых LLM на каждом документе в больших масштабах стоил бы целое состояние.
LLMs can read and reason about this data. But applying them naively to thousands of documents is slow, expensive, and often inaccurate. You can’t just point a powerful model at a mountain of PDFs and expect good results.
LLM могут читать эти данные и рассуждать о них. Но наивное применение их к тысячам документов — это медленно, дорого и часто неточно. Нельзя просто направить мощную модель на гору PDF-файлов и ожидать хороших результатов.
Semantic Data Processing
Семантическая обработка данных
Traditional databases use operators like SELECT, GROUP BY, and JOIN on structured tables. The emerging field of semantic data processing applies a similar idea to unstructured text, using LLMs to power new “semantic operators.”
Традиционные базы данных используют операторы вроде SELECT, GROUP BY и JOIN над структурированными таблицами. Развивающаяся область семантической обработки данных применяет похожую идею к неструктурированному тексту, используя LLM для работы новых «семантических операторов».
(The slide shows a pipeline that extracts judge names from court transcripts, then groups by judge to summarize bias patterns. The output schema is explicit: the user declares what attributes they want, and the LLM populates them. Users don’t write procedural code; they describe the output they need.
На слайде показан пайплайн, который извлекает имена судей из судебных стенограмм, затем группирует по судье, чтобы обобщить паттерны предвзятости. Выходная схема задаётся явно: пользователь объявляет, какие атрибуты ему нужны, а LLM их заполняет. Пользователи не пишут процедурный код; они описывают нужный им результат.
This paradigm is already being adopted by major databases like Databricks, Google BigQuery, and Snowflake under names like AI SQL. Shreya’s research focuses on two key questions:
Эта парадигма уже принимается на вооружение крупными базами данных, такими как Databricks, Google BigQuery и Snowflake, под названиями вроде AI SQL. Исследования Shreya сосредоточены на двух ключевых вопросах:
Масштабируемость: Как сделать эти семантические пайплайны быстрыми и дешёвыми? Управляемость: Как помочь пользователям контролировать AI, чтобы получать нужные результаты?
docETL: Building Scalable Pipelines
docETL: Создание масштабируемых пайплайнов
Shreya’s open-source system, docETL, implements semantic operators for text. A dataset in docETL is a collection of documents (like a list of JSON objects).
Открытая система Shreya, docETL, реализует семантические операторы для текста. Датасет в docETL — это коллекция документов (как список JSON-объектов).
(docETL is built on three main operators:
docETL построен на трёх основных операторах:
1. Semantic Map: Applies a one-to-one transformation to each document.
1. Семантический Map: Применяет преобразование один-к-одному к каждому документу.
(The number of documents in equals the number out. Each document gets enriched with new attributes (statements, explanation), but the collection size stays the same.
Число документов на входе равно числу на выходе. Каждый документ обогащается новыми атрибутами (statements, explanation), но размер коллекции остаётся прежним.
2. Semantic Filter: The slide shows 10,000 documents reduced to 138, a 99% reduction from a single natural language predicate. Cost savings compound because downstream operators only process the 138 that passed.
2. Семантический Filter: На слайде показано, как 10 000 документов сокращаются до 138 — снижение на 99% от одного предиката на естественном языке. Экономия затрат накапливается, потому что нижестоящие операторы обрабатывают только те 138, что прошли фильтр.
(3. Semantic Reduce: Groups documents by a key and applies an aggregation. The slide shows grouping by judge name. Notice the output: 250 judges from 10,000 transcripts. The LLM must synthesize information across many documents into a single summary per group, and context window limits constrain how many documents can be processed together.
3. Семантический Reduce: Группирует документы по ключу и применяет агрегацию. На слайде показана группировка по имени судьи. Обратите внимание на вывод: 250 судей из 10 000 стенограмм. LLM должна синтезировать информацию из множества документов в единое резюме на каждую группу, и ограничения контекстного окна сдерживают то, сколько документов можно обработать вместе.
(The power comes from composing these operators. Filter early. Map to extract structure. Reduce to aggregate. Placing an expensive map before a filter wastes compute on documents you’ll discard anyway.
Сила приходит от композиции этих операторов. Фильтруй рано. Применяй map, чтобы извлечь структуру. Используй reduce для агрегации. Размещение дорогого map перед фильтром тратит вычисления на документы, которые вы всё равно отбросите.
Optimizing Semantic Pipelines
Оптимизация семантических пайплайнов
A naive execution of this pipeline, running a state-of-the-art LLM on every document, would be expensive. The key contribution of docETL is a query optimizer that makes these pipelines both cheaper and more accurate.
Наивное выполнение такого пайплайна — запуск передовой LLM на каждом документе — было бы дорогим. Ключевой вклад docETL — это оптимизатор запросов, делающий эти пайплайны одновременно дешевле и точнее.
(It draws inspiration from traditional database optimizers but adapts them for the fuzzy, expensive nature of LLMs. The core idea is rewrite directives: rules for transforming a user’s pipeline into a more efficient, equivalent one.
Он черпает вдохновение из традиционных оптимизаторов баз данных, но адаптирует их под нечёткую и дорогую природу LLM. Ключевая идея — директивы переписывания: правила преобразования пользовательского пайплайна в более эффективный, эквивалентный.
(Rewrite for Accuracy: Decomposing the Task
Переписывание ради точности: Декомпозиция задачи
LLMs struggle with long documents or complex instructions. A single prompt asking for four different attributes from a 100-page document might miss some of them. docETL improves accuracy by breaking the problem down.
LLM плохо справляются с длинными документами или сложными инструкциями. Один промпт, запрашивающий четыре разных атрибута из 100-страничного документа, может упустить некоторые из них. docETL повышает точность, разбивая проблему на части.
Декомпозиция данных (Split-Map-Reduce): Система разбивает документы на чанки перед обработкой. Размер чанка подбирается эмпирически: слишком маленький — теряется контекст; слишком большой — LLM упускает детали, спрятанные в середине. Шаг слияния требует тщательного проектирования, потому что чанки порождают перекрывающиеся или противоречащие извлечения. Если два чанка оба извлекают «Судья Смит сделал предвзятое заявление», операция reduce должна устранить дубликаты. Если они извлекают противоречивую информацию, она должна согласовать их или пометить конфликт.
(docETL can create a pipeline of simpler prompts. A prompt asking for four attributes can be rewritten into four separate map operations, each extracting one attribute, followed by an operation to unify the results.Декомпозиция задачи: Вместо одного сложного промпта docETL может создать пайплайн из более простых промптов. Промпт, запрашивающий четыре атрибута, можно переписать в четыре отдельные операции map, каждая из которых извлекает по одному атрибуту, за которыми следует операция, объединяющая результаты.
(Rewrite for Cost: Reducing LLM Calls
Переписывание ради стоимости: Сокращение вызовов LLM
docETL also uses rewrites to cut costs:
docETL также использует переписывания для снижения затрат:
Слияние операторов (Operator Fusion): Объединяет два простых, идущих подряд оператора в один вызов LLM. Синтез кода (Code Synthesis): Заменяет простой семантический оператор (например, конкатенацию списка результатов) на бесплатную Python-функцию.
(docETL can insert an initial, cheap step (like a keyword or embedding search) to extract only the relevant sections, dramatically reducing the amount of text sent to expensive downstream LLMs.Проталкивание проекции (Projection Pushdown): Если пайплайну нужны только небольшие части крупного документа, docETL может вставить начальный, дешёвый шаг (вроде поиска по ключевым словам или по эмбеддингам), чтобы извлечь только релевантные секции, резко сокращая объём текста, отправляемого дорогим нижестоящим LLM.
(Coming up with these rewrite directives required inventing new operator types beyond basic map/filter/reduce:
Чтобы придумать эти директивы переписывания, потребовалось изобрести новые типы операторов помимо базовых map/filter/reduce:
Gather Operator: When you split documents into chunks, individual chunks often make no sense in isolation. Who is “he”? What contract are they referring to? The Gather operator augments each chunk with useful context: a sliding window of previous chunks, a summary of the document so far, or metadata like a table of contents. This lets the LLM make sense of each chunk during split-map-reduce rewrites.
Resolve Operator: Entity resolution as a first-class citizen. If you want to group by an LLM-extracted attribute (like judge names), the LLM often extracts inconsistently: “Judge Smith”, “J. Smith”, “the Honorable Smith”. The Resolve operator normalizes these before the group-by, ensuring all documents land in the correct group.
Оператор Gather: Когда вы разбиваете документы на чанки, отдельные чанки часто не имеют смысла в изоляции. Кто такой «он»? О каком контракте они говорят? Оператор Gather дополняет каждый чанк полезным контекстом: скользящим окном предыдущих чанков, резюме документа до этого места или метаданными вроде оглавления. Это позволяет LLM осмыслить каждый чанк во время переписываний split-map-reduce. Оператор Resolve: Разрешение сущностей как полноправный гражданин. Если вы хотите группировать по извлечённому LLM атрибуту (например, именам судей), LLM часто извлекает их непоследовательно: «Судья Смит», «Дж. Смит», «достопочтенный Смит». Оператор Resolve нормализует их перед группировкой, гарантируя, что все документы попадут в правильную группу.
Task Cascades: The Cost-Accuracy Trade-off
Каскады задач: компромисс между стоимостью и точностью
To manage the trade-off between cost and accuracy, docETL uses Task Cascades, a generalization of model cascades (a classic technique where cheap models handle easy cases and expensive models handle hard ones).
Чтобы управлять компромиссом между стоимостью и точностью, docETL использует Каскады задач (Task Cascades) — обобщение каскадов моделей (классической техники, где дешёвые модели обрабатывают лёгкие случаи, а дорогие — сложные).
(The slide shows a cascade for the question “Does this opinion overturn a lower court decision?” Rather than running GPT-4o on every document, the system first asks cheaper questions: “Is there any lower court mentioned?” and “Does it say remanding?” These proxies eliminate obvious negatives. Only ambiguous cases reach the expensive oracle.
На слайде показан каскад для вопроса «Отменяет ли это заключение решение нижестоящего суда?». Вместо запуска GPT-4o на каждом документе система сначала задаёт более дешёвые вопросы: «Упоминается ли вообще нижестоящий суд?» и «Говорится ли о возврате дела на пересмотр?». Эти прокси отсеивают очевидные отрицательные случаи. До дорогого оракула доходят только неоднозначные случаи.
A task cascade can vary three things: the model (cheap vs. expensive), the data (summary vs. full text), and the task itself (simpler correlated question vs. the real question). Most documents have obvious answers: a court opinion that never mentions a lower court clearly doesn’t overturn one. A well-designed cascade resolves 80-90% of cases with cheap proxy checks, reserving expensive calls for genuinely ambiguous inputs.
Каскад задач может варьировать три вещи: модель (дешёвая против дорогой), данные (резюме против полного текста) и саму задачу (более простой коррелирующий вопрос против настоящего вопроса). У большинства документов ответы очевидны: судебное заключение, которое никогда не упоминает нижестоящий суд, явно его не отменяет. Хорошо спроектированный каскад разрешает 80–90% случаев дешёвыми прокси-проверками, оставляя дорогие вызовы для по-настоящему неоднозначных входов.
By constructing an optimal sequence of these proxy tasks, docETL can reduce costs by up to 86% while staying within 90% of target accuracy.
Выстраивая оптимальную последовательность таких прокси-задач, docETL может снизить затраты до 86%, оставаясь в пределах 90% целевой точности.
A Global Search for the Best Plan
Глобальный поиск лучшего плана
Unlike traditional databases, there is no single “best” plan. The optimal pipeline depends on the user’s budget and accuracy requirements. docETL uses a global search algorithm inspired by Monte Carlo Tree Search to explore the space of possible rewrites.
В отличие от традиционных баз данных, единого «лучшего» плана не существует. Оптимальный пайплайн зависит от бюджета пользователя и требований к точности. docETL использует алгоритм глобального поиска, вдохновлённый Monte Carlo Tree Search, чтобы исследовать пространство возможных переписываний.
Why not just optimize each operator independently? Because operators interact. The way you execute operator 3 depends on the implementations you chose for operators 1 and 2. Downstream operators can correct, augment, or interpret upstream results differently. You need to consider complete pipelines, not subexpressions.
Почему бы просто не оптимизировать каждый оператор независимо? Потому что операторы взаимодействуют. То, как вы выполняете оператор 3, зависит от реализаций, выбранных для операторов 1 и 2. Нижестоящие операторы могут исправлять, дополнять или интерпретировать результаты вышестоящих по-разному. Нужно рассматривать целые пайплайны, а не подвыражения.
(The search treats pipelines as nodes in a graph. Each edge is a rewrite. An LLM agent selects which rewrite directive to apply, reads sample data, and instantiates the new prompts. The system uses UCB-inspired selection to prioritize rewriting pipelines that are both high-quality and likely to produce children on the Pareto frontier.
Поиск рассматривает пайплайны как узлы графа. Каждое ребро — это переписывание. LLM-агент выбирает, какую директиву переписывания применить, читает примеры данных и создаёт новые промпты. Система использует отбор в духе UCB, чтобы приоритизировать переписывание тех пайплайнов, которые одновременно высококачественны и вероятно породят потомков на Парето-фронте.
On real workloads from public defenders and journalists, docETL’s optimizer finds the most accurate query plan every time, often 2x more accurate than competing systems like Stanford’s Lotus or MIT’s Polyest/Abacus. It also outperforms a GPT-5 agent given access to the same query engine and documentation. The agent can test pipelines on samples and iterate freely, but carefully designed rewrite directives still win.
На реальных рабочих нагрузках от государственных защитников и журналистов оптимизатор docETL каждый раз находит наиболее точный план запроса — часто вдвое точнее конкурирующих систем, таких как Lotus из Stanford или Polyest/Abacus из MIT. Он также превосходит агента на базе GPT-5, которому дали доступ к тому же движку запросов и документации. Агент может тестировать пайплайны на выборках и свободно итерировать, но тщательно спроектированные директивы переписывания всё равно побеждают.
Doc Wrangler: An IDE for Steering AI
Doc Wrangler: IDE для управления AI
A scalable system is not enough if users can’t express what they want. Shreya’s team built Doc Wrangler, an interactive development environment (IDE) for authoring docETL pipelines.
Масштабируемой системы недостаточно, если пользователи не могут выразить то, что им нужно. Команда Shreya построила Doc Wrangler — интерактивную среду разработки (IDE) для создания пайплайнов docETL.
(The design is guided by a framework called the Three Gulfs, which identifies the gaps users face when working with AI on unstructured data.
Дизайн направляется фреймворком под названием Три разрыва (Three Gulfs), который выделяет пробелы, с которыми сталкиваются пользователи при работе с AI над неструктурированными данными.
(1. The Gulf of Comprehension: What’s in my data?
1. Разрыв понимания: Что в моих данных?
Users often don’t know the full range of content and edge cases in their documents. You can’t write good prompts for data you don’t understand.
Пользователи часто не знают всего диапазона содержимого и краевых случаев в своих документах. Нельзя написать хорошие промпты для данных, которых не понимаешь.
Решение Doc Wrangler: Он предоставляет инспектор для просмотра выводов оператора бок о бок с исходным документом. Пользователи могут оставлять заметки и фидбэк по примерам — процесс, похожий на открытое кодирование (open coding) в качественном анализе.
(An example: a medical analyst processes doctor-patient conversation transcripts to extract medications. As they inspect outputs, they notice something: every medication mention is accompanied by a dosage. They didn’t know this when they started. Now they realize they want dosages extracted too. Or they see over-the-counter medications like Tylenol appearing and decide they only want prescription medications.
Пример: медицинский аналитик обрабатывает стенограммы разговоров врача с пациентом, чтобы извлечь лекарства. Инспектируя выводы, он замечает кое-что: каждое упоминание лекарства сопровождается дозировкой. Он не знал этого, когда начинал. Теперь он понимает, что хочет извлекать ещё и дозировки. Или он видит появляющиеся безрецептурные препараты вроде Tylenol и решает, что ему нужны только рецептурные лекарства.
These notes persist in the sidebar. In practice, users accumulate 25-30 notes as they open-code their data, and the accumulated notes reveal patterns: “I keep flagging over-the-counter drugs” becomes the realization “I only want prescription medications.”
Эти заметки остаются на боковой панели. На практике пользователи накапливают 25–30 заметок, пока открыто кодируют свои данные, и накопленные заметки выявляют паттерны: «я постоянно помечаю безрецептурные препараты» превращается в осознание «мне нужны только рецептурные лекарства».
A finding from user studies: people invented their own strategies to bridge this gulf. They wrote “throwaway pipelines”: summarize these documents, extract the key ideas. Operations with no analytical purpose. Just ways to learn what’s in the data before doing the real analysis.
Находка из пользовательских исследований: люди изобретали собственные стратегии, чтобы перекрыть этот разрыв. Они писали «одноразовые пайплайны»: обобщи эти документы, извлеки ключевые идеи. Операции без аналитической цели. Просто способы узнать, что в данных, прежде чем приступать к настоящему анализу.
2. The Gulf of Specification: How do I write the right prompt?
2. Разрыв спецификации: Как написать правильный промпт?
Users accumulate dozens of observations about their data but struggle to translate them into prompt language. “Only prescription medications” is clear to a human but must be operationalized: does that mean exclude Tylenol? What about insulin, which is prescription but also available over-the-counter in some states?
Пользователи накапливают десятки наблюдений о своих данных, но с трудом переводят их на язык промпта. «Только рецептурные лекарства» понятно человеку, но должно быть операционализировано: означает ли это исключить Tylenol? А как насчёт инсулина, который рецептурный, но в некоторых штатах также доступен без рецепта?
Решение Doc Wrangler: Он использует LLM, чтобы синтезировать заметки и фидбэк пользователя с шага понимания в предлагаемый, улучшенный промпт.
(3. The Gulf of Generalization: Will this work at scale?
3. Разрыв обобщения: Будет ли это работать в масштабе?
A prompt that works on a few examples might fail on a larger dataset because it has become too complex for the LLM to follow reliably.
Промпт, который работает на нескольких примерах, может провалиться на большем датасете, потому что стал слишком сложным, чтобы LLM могла надёжно ему следовать.
docETL rewrite to decompose the complex operation into a pipeline of simpler, more reliable ones.Решение Doc Wrangler: Он автоматически запускает LLM-судью на выборке выводов, чтобы обнаружить, когда многосоставная задача начинает давать сбои. Если он находит неточный компонент, он предлагает переписывание docETL, чтобы разложить сложную операцию на пайплайн из более простых и надёжных.
(The Final Challenge: Evaluation
Финальный вызов: Оценка
How do you know if your pipeline is actually working? For subjective tasks like “find mentions of racial bias,” there are no pre-existing labels. This isn’t like code where you can check if it runs. There’s no ground truth.
Как понять, действительно ли ваш пайплайн работает? Для субъективных задач вроде «найти упоминания расовой предвзятости» нет заранее готовых меток. Это не как с кодом, где можно проверить, запускается ли он. Здесь нет эталонной истины (ground truth).
This challenge led to the EvalGen project and a key insight: evaluation criteria drift.
Этот вызов привёл к проекту EvalGen и ключевому инсайту: дрейф критериев оценки.
(When users begin evaluating LLM outputs, their own understanding of the task evolves. They start with a simple rubric, but as they see more examples, they refine it.
Когда пользователи начинают оценивать выводы LLM, их собственное понимание задачи эволюционирует. Они стартуют с простого рубрикатора, но по мере просмотра большего числа примеров уточняют его.
An example: users evaluated an entity extraction task on tweets. One rule: “Don’t extract hashtags as entities.” When they saw hashtags extracted, they marked it wrong. But when #ColinKaepernick kept appearing (a famous football player), some users changed their mind. “Actually, that’s a notable entity. I’m glad it was extracted.” After seeing it multiple times, they refined the rule: “Don’t extract hashtags, unless they represent a notable entity.”
Пример: пользователи оценивали задачу извлечения сущностей на твитах. Одно правило: «Не извлекать хэштеги как сущности». Когда они видели извлечённые хэштеги, они помечали это как ошибку. Но когда раз за разом появлялся #ColinKaepernick (знаменитый футболист), некоторые пользователи передумали. «На самом деле это заметная сущность. Я рад, что её извлекли». Увидев это несколько раз, они уточнили правило: «Не извлекать хэштеги, если только они не представляют заметную сущность».
Standard ML evaluation assumes fixed criteria: define metrics upfront, collect labels, measure performance. But users wanted to add new criteria as they discovered failure modes and reinterpret existing criteria to better fit the LLM’s behavior. EvalGen supports this: it solicits labels on outputs as they’re generated, builds LLM-based evaluators that reflect the user’s refined criteria, and produces report cards showing how well outputs align with intentions.
Стандартная ML-оценка предполагает фиксированные критерии: определить метрики заранее, собрать метки, измерить производительность. Но пользователи хотели добавлять новые критерии по мере обнаружения режимов сбоя и переинтерпретировать существующие критерии, чтобы лучше соответствовать поведению LLM. EvalGen это поддерживает: он запрашивает метки на выводах по мере их генерации, строит LLM-оценщиков, отражающих уточнённые критерии пользователя, и выдаёт «табели успеваемости», показывающие, насколько хорошо выводы соответствуют намерениям.
Shreya and I co-developed these ideas for our LLM Evals course. The ideas have been adopted by major LLM ops companies and featured in the OpenAI cookbook.
Shreya и я совместно разработали эти идеи для нашего курса LLM Evals. Эти идеи приняли на вооружение крупные LLM-ops компании, и они представлены в OpenAI cookbook.
Key Takeaways
Ключевые выводы
Processing documents with LLMs is more than prompt engineering. Building robust systems requires integrating ideas from databases, HCI, and AI:
Обработка документов с помощью LLM — это больше, чем prompt engineering. Создание надёжных систем требует интеграции идей из баз данных, HCI и AI:
map, filter, reduce) to structure unstructured data processing tasks in a familiar, composable way.Структурируйте проблему: Используйте семантические операторы (map, filter, reduce), чтобы структурировать задачи обработки неструктурированных данных привычным, компонуемым образом. Оптимизируйте систему: Используйте оптимизатор запросов с директивами переписывания, чтобы автоматически преобразовывать пайплайны ради лучшей стоимости и точности. Техники вроде декомпозиции задач и каскадов задач незаменимы. Расширяйте возможности пользователя: Стройте интерактивные инструменты, которые помогают пользователям понимать свои данные, специфицировать свои намерения и справляться со сбоями в масштабе. Три разрыва дают полезный фреймворк для проектирования. Итерируйте над оценкой: Признайте, что сами критерии оценки будут эволюционировать. Постройте плотную петлю обратной связи, где вы непрерывно размечаете данные, анализируете сбои и уточняете своё определение успеха.
Q&A Session
Сессия вопросов и ответов
Does the DocWrangler UX generalize to other AI problems? (Timestamp: 56:50) This was a surprise finding. Shreya originally thought the Three Gulfs were specific to document processing. But AI engineers in user studies immediately recognized the pattern. When programming agents, you face the same problem: agents make tool calls, exhibit reasoning paths, behave in ways you can’t anticipate. You need interfaces to inspect traces, leave feedback, and iteratively refine. The Gulf of Comprehension isn’t just about data; it’s about understanding any system behavior you didn’t anticipate. The model generalizes beyond documents to any complex AI system.
Why does this research look so much like a product? (Timestamp: 01:00:10) Two reasons. First, data systems research is inherently applied. It solves problems for a trillion-dollar industry. Every paper involves building systems people can use. Second, Shreya combines this with HCI, which demands building usable interfaces to test theories about human-AI collaboration. This “double whammy” produces research that looks like startup pitch decks: working software, user interviews, pain point analysis, product workflows. (I joke with Shreya about this regularly.) But she’s an academic at heart. The goal is discovering novel interface paradigms, not building companies.
Why isn’t data processing as hyped as chatbots? (Timestamp: 01:03:36) The data management community is significantly smaller than the AI/ML community. However, the industrial utility is massive. There is a huge opportunity in educating engineers on building scalable, semantic data systems, which is what Shreya aims to focus on.
Should we use Knowledge Graphs for these problems? (Timestamp: 01:07:10) Often, no. Shreya sees this question constantly, and the answer is usually that people make their lives harder by reaching for graphs. When she asks “why do you want a graph?”, users often realize they just wanted entities extracted and grouped. Not all pairs of edges between all entities. Most workloads are ETL-style: transform data to get specific entities or aggregations. If the end goal isn’t complex traversal (finding paths between disparate nodes), forcing data into a graph structure adds unnecessary friction. You spend time putting data into a graph database only to need tools like docETL to wrangle it back out.
How do you handle multi-hop reasoning across document pages? (Timestamp: 01:09:11) This is solved via the Gather operator. Instead of “hopping” indiscriminately, the system processes chunks linearly but augments them. If a chunk requires context from page 1 to be understood, the Gather operator retrieves that context and attaches it to the chunk before processing. This effectively linearizes the reasoning dependency.
How are confidence scores assessed in Task Cascades? (Timestamp: 01:13:17) Confidence is derived from log probabilities of the LLM’s generation, calibrated against an Oracle model (e.g., GPT-4o). The system iterates through threshold values on a sample set to find the cutoff that maintains the target accuracy relative to the Oracle.
Обобщается ли 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). Система перебирает пороговые значения на тестовой выборке, чтобы найти отсечку, которая поддерживает целевую точность относительно оракула.
👉 Want to learn more about evaluating LLM pipelines? Check out our AI Evals course, which Shreya and I co-developed. It’s a live cohort with hands-on exercises and office hours. Here is a 25% discount code for readers. 👈
👉 Хотите узнать больше об оценке LLM-пайплайнов? Загляните на наш курс AI Evals, который Shreya и я разработали совместно. Это живой когортный курс с практическими упражнениями и часами консультаций. Вот промокод на скидку 25% для читателей. 👈
Video
Видео
Here is the full video:
Вот полное видео: