Document Processing Automation with LLMs: Evolution of Evaluation Strategies

tola_capital_/_klarity · Finance · 2023 · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Evaluation strategy for production LLM document workflows

Klarity needed evaluation methods for fast-moving, multi-LLM document automation workflows where generic leaderboards, delayed eval builds, and abstract accuracy metrics did not track customer experience.

Constraints:

• Klarity automates cognitive, negotiated back-office documents for finance and accounting.
• Features can ship in days, so multi-week evaluation builds become a bottleneck.
• Generic benchmarks can diverge from internal task performance.
• Customer-specific prompts and use cases can explode into thousands of combinations.
• Synthetic data must remain distributionally similar to customer data.

Architecture

Klarity's evaluation strategy starts with UX risk before full eval construction, then works backward from user value to task-specific accuracy metrics. For large enough use cases, the company builds customer-agnostic synthetic-data evals, monitors data drift and synthetic-data distribution, and reduces degrees of freedom in its multi-LLM architecture, for example by fixing one LLM for automated-prompt-engineering tasks rather than grid-searching every customer/task combination.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  customer-document-workflows["Customer document workflows"] --> multi-llm-application-stack["Multi-LLM application stack"]
  multi-llm-application-stack --> ux-testing["UX testing"]
  ux-testing --> task-specific-eval-metrics["Task-specific eval metrics"]
  multi-llm-application-stack --> task-specific-eval-metrics["Task-specific eval metrics"]
  task-specific-eval-metrics --> synthetic-data-generation-stack["Synthetic data generation stack"]
  synthetic-data-generation-stack --> data-drift-monitoring["Data drift monitoring"]
  data-drift-monitoring --> task-specific-eval-metrics["Task-specific eval metrics"]
  degrees-of-freedom-controls["Degrees-of-freedom controls"] --> multi-llm-application-stack

Components

Data flow

Customer documents flow through LLM-based extraction, matching, tabular extraction, table composition, and other document workflows. User testing identifies whether the experience is worth scaling. Production-bound use cases then receive task-specific evals, synthetic datasets, drift monitoring, and simplified model/prompt dimensions so teams can iterate without a combinatorial evaluation burden.

Why this architecture

Klarity organizes evaluation around user experience and production task value because generic model benchmarks and raw F1-style metrics do not reliably represent document-workflow success. The synthetic-data and degrees-of-freedom strategy keeps evals tractable despite many customers, tasks, prompts, and LLMs.

Models used: More than 10 LLMs under the hood · Multiple LLMs per use case · Automated prompt engineers · Custom synthetic data generation stack

Scale

• Klarity raised a $70 million Series B.
  “$70 million series B financing on Monday”transcript, stated
• The company processed more than half a million customer documents.
  “than half a million documents for customers”transcript, stated
• Klarity had more than 15 unique LLM production use cases and more than 10 LLMs under the hood.
  “we have more than 15 unique llm use cases running in in production today uh and more than 10 llms under the hood”transcript, stated
• Feature development accelerated from weeks to days in some cases.
  “now what we're seeing is we can get features out of the door in days”transcript, stated
• Document chat launched within 12 hours of ChatGPT launch.
  “within 12 hours of the chat GPT launch we launch document chat as a feature”transcript, stated

Alternatives considered (roads not taken)

Build polished evals at the start of every feature

Rejected because: Good evals are expensive and many features fail at the UX stage before full eval investment is worthwhile.

Measure whatever is easy, such as generic F1

Rejected because: The framework starts from end-user value and works backward to evals.

Grid-search every LLM/customer/task/prompt combination

Rejected because: The complexity was too expensive; they fixed one model dimension where commonality appeared.

Patterns

eval-driven-development (evaluation)

Klarity builds evals backward from user experience and customer-specific task accuracy rather than from generic benchmarks.

synthetic-data-generation (evaluation)

Klarity built an in-house synthetic data generation stack for customer-agnostic evals once a use case became large enough.

model-routing (model-ops)

The production platform uses more than 10 LLMs and sometimes multiple LLMs within a single use case.

data-quality-loop (data)

Synthetic data is monitored for distributional similarity to customer documents and paired with drift monitoring.

Tradeoffs

Frontload UX testing

Chose Early user-experience validation over Full eval build before every experiment.

Rationale: Many generative AI features fail because the experience is wrong, so expensive evals should not precede basic UX validation.

Build synthetic data internally

Chose In-house synthetic data generation stack over Buying a provider solution.

Rationale: Klarity tried six-plus providers and was not satisfied with fit for its eval needs.

Fix one LLM dimension for automated prompt engineering tasks

Chose One LLM for AP tasks, with reevaluation over time over Max-accuracy grid search across all customers/tasks.

Rationale: The team accepted possibly losing a small accuracy point to avoid infrastructure complexity and speed iteration.

Gotchas (what bit them)

Eval construction can become the feature-development bottleneck.

Root cause: Feature cycles accelerated to days while thoughtful evals could take one to three weeks.

Resolution: Frontload UX testing and delay full eval investment until a feature is production-bound.

Benchmark leaderboards can mislead production decisions.

Root cause: Small benchmark differences do not necessarily match Klarity's internal document-workflow tasks.

Resolution: Build task/customer-specific internal benchmarks and customer-agnostic evals.

Customer-specific prompt/model grids explode combinatorially.

Root cause: Many customers, tasks, prompts, and LLM choices multiply into thousands of combinations.

Resolution: Reduce degrees of freedom by fixing some model dimensions while continuously reevaluating as models change.

Evaluation

Klarity evaluates document automation through user-experience-first task metrics, customer-specific accuracy metrics, synthetic-data evals, data drift monitoring, and future-facing eval wish lists.

Metrics: Customer-specific extraction/matching accuracy · User-experience success · Data drift against customer document populations · Synthetic-data distributional similarity · Internal benchmarks versus model leaderboard benchmarks

Outcomes

• Processes more than half a million customer documents.
• Runs more than 15 unique LLM use cases in production.
• Uses more than 10 LLMs under the hood, with multiple LLMs in some use cases.
• Built a pragmatic eval strategy around UX, task-specific metrics, synthetic data, and controlled model complexity.

The source reports more than half a million documents, 15+ LLM production use cases, 10+ LLMs, and over 100 customers as a driver of prompt/model complexity.