Data ExtractionDocument AILLM API

Trích xuất dữ liệu LLM: PDF sang JSON có cấu trúc (2026)

1 phút đọc

Pipeline hóa đơn đã nạp 40,000 tài liệu trong quý trước. Báo cáo đối soát trông hoàn hảo — cho đến khi ai đó phát hiện 3% trường nhà cung cấp sai một cách âm thầm: một mã số hóa đơn bị đảo chữ số, một dòng thuế bị gắn vào hàng sai, một ký hiệu tiền tệ bị rơi mất. Không ai nhận ra, vì quá trình trích xuất không hề thất bại. Nó thành công — với câu trả lời sai.

Đó chính là nỗi kinh hoàng đặc trưng của trích xuất tài liệu: thất bại âm thầm. Không có lỗi 500 khi một trường schema trả về trống-nhưng-đã-qua-xác-thực, không có exception khi một cột bảng bị lệch. Trích xuất dữ liệu bằng LLM là một trong những khối lượng công việc LLM giá trị nhất trong năm 2026 — hóa đơn, hợp đồng, biểu mẫu, yêu cầu bồi thường — và cũng là một trong những thứ gây hiểu lầm benchmark nhất, vì benchmark của nhà cung cấp do chính nhà cung cấp viết, trên những tài liệu làm nổi bật parser của họ.

Hướng dẫn này bao quát pipeline trích xuất từ đầu đến cuối — parse, schema, extract, validate — với câu hỏi benchmark trung thực (LLM-only so với nhà cung cấp parsing so với mã nguồn mở, trên tài liệu của bạn), thiết kế schema ngăn chặn hỏng hóc âm thầm, xử lý PII giữ mọi thứ hợp pháp, và mô hình chi phí mỗi 1,000 tài liệu.

Trích xuất tài liệu thực sự bao gồm những gì

Điểm chính: trích xuất là một chuỗi năm giai đoạn — parsing, hiểu, tạo schema, trích xuất, xác thực — và bất kỳ giai đoạn nào cũng có thể thất bại âm thầm.

PDF → 1. Parse (layout, tables, OCR) → 2. Understand (vision or text)
        → 3. Schema (what fields, what types) → 4. Extract (LLM)
        → 5. Validate (types, required, confidence) → JSON

Chuỗi chỉ mạnh bằng giai đoạn yếu nhất, và các giai đoạn thất bại theo những cách khác nhau: parsing hỏng trên tài liệu quét và bố cục nhiều cột, hiểu hỏng trên nội dung bị xoay hoặc có watermark, schema hỏng khi trường bị thiếu mà không ai nhận ra, và xác thực hỏng khi nó không được triển khai chút nào. Việc của pipeline là làm cho mọi thất bại trở nên ồn ào thay vì âm thầm.

Vì sao trích xuất thất bại trong production

Điểm chính: ba lớp thất bại — lỗi parse, schema trôi dạt và thiếu xác thực — và chỉ một trong số đó xuất hiện trong log.

  1. Lỗi parsing. Tài liệu quét không có OCR, bảng bị đọc thành một mớ văn bản, bố cục nhiều cột bị làm phẳng thành thứ tự rác. Parser quyết định trần; LLM không thể trích xuất thứ mà parser đã phá hủy.
  2. Schema trôi dạt. Tài liệu thay đổi — một trường mới xuất hiện, một nhà cung cấp đổi template — còn schema thì đứng yên. Quá trình trích xuất âm thầm trả về các trường thiếu vẫn qua xác thực vì “thiếu” không phải là một quy tắc.
  3. Thiếu xác thực. Không kiểm tra kiểu dữ liệu, không có quy tắc trường bắt buộc, không chấm điểm độ tin cậy. Pipeline trả về JSON, và JSON trông đúng nhưng thực ra sai còn tệ hơn không có JSON: nó bơm vào các hệ thống hạ nguồn những dữ liệu sai trông hợp lý.

Các so sánh của chính ngành — như cuộc đối đầu parser 2026 của pdfmux — cho thấy một cách nhất quán rằng lựa chọn parser làm thay đổi độ chính xác nhiều hơn lựa chọn model. Đó là bài học đầu tiên: hãy benchmark parser trên tài liệu của bạn trước khi benchmark model.

Bài kiểm tra trung lập: LLM-Only so với Parser so với Mã nguồn mở

Điểm chính: hãy chạy bài kiểm tra ba chiều trên corpus của chính bạn — tài liệu văn bản đơn giản, tài liệu quét lộn xộn và bảng — vì thứ hạng đảo ngược theo loại tài liệu.

Bức tranh 2026 có ba gia đình:

  • LLM-only — đưa tài liệu (văn bản hoặc hình ảnh) thẳng vào một multimodal model. Hoạt động tốt trên PDF kỹ thuật số sạch; suy giảm trên bố cục phức tạp.
  • Nhà cung cấp parsing — LlamaParse, Unstructured và các đối thủ cùng phân khúc, những người chuẩn hóa bố cục trước khi đưa cho LLM. Dẫn đầu benchmark trên tài liệu phức tạp, với chi phí tính theo trang.
  • Mã nguồn mở — Docling, Marker và các model chuyên trích xuất mới hơn như NuExtract3 (một vision-language model open-weight 4B được xây cho trích xuất có cấu trúc, tự lưu trữ được theo cấu trúc giá của NuExtract). Kiểm soát và trần chi phí, đổi lại là chi phí vận hành.

Bài kiểm tra quyết định: ba bộ tài liệu — kỹ thuật số sạch, quét, nhiều bảng — chạy qua cả ba gia đình, đo theo độ chính xác cấp trường (không phải so khớp “trông giống”), chi phí mỗi 1,000 tài liệu và tỷ lệ thất bại. Dự đoán trung thực: LLM-only thắng bộ tài liệu sạch, nhà cung cấp thắng bộ tài liệu quét, và mã nguồn mở thắng cột chi phí ở khối lượng lớn — và corpus của bạn quyết định cột nào quan trọng.

Cách lắp ráp pipeline: Parse → Schema → Extract → Validate

Điểm chính: thiết kế schema là giai đoạn có đòn bẩy cao nhất — một schema chặt chẽ kèm xác thực biến trích xuất từ hy vọng thành hợp đồng.

Vòng lặp cốt lõi, không phụ thuộc nhà cung cấp — trên endpoint hợp nhất:

import json
from openai import OpenAI

client = OpenAI()  # unified endpoint

SCHEMA = {  # the contract: required fields fail loudly
    "type": "object",
    "required": ["invoice_number", "vendor", "total"],
    "properties": {
        "invoice_number": {"type": "string"},
        "vendor": {"type": "string"},
        "total": {"type": "number"},
        "currency": {"type": "string", "enum": ["USD", "EUR", "GBP"]},
    },
}

def extract(page_text: str) -> dict:
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        response_format={"type": "json_schema", "json_schema": {"name": "invoice", "schema": SCHEMA}},
        messages=[{"role": "user", "content": f"Extract the invoice data as JSON:\n{page_text}"}],
    )
    return json.loads(resp.choices[0].message.content)

def validate(doc: dict) -> tuple[bool, list[str]]:
    errors = []
    for field in SCHEMA["required"]:
        if field not in doc or doc[field] in (None, ""):
            errors.append(f"missing required field: {field}")
    if not isinstance(doc.get("total"), (int, float)):
        errors.append("total is not a number")
    return (not errors, errors)

Bốn quy tắc đưa nó lên cấp production:

  1. Schema là một hợp đồng. Trường bắt buộc, enum và kiểu dữ liệu — được thực thi bởi chế độ structured output của model (mô hình được ghi chép trong loạt bài này) — để “thiếu” trở thành một lỗi thay vì một key vắng mặt.
  2. Parse trước khi prompt. PDF kỹ thuật số đi thẳng vào LLM; tài liệu quét đi qua OCR hoặc một multimodal model. Danh mục model cho bạn biết model nào chấp nhận hình ảnh; quy tắc quyết định là “parser có nhìn thấy văn bản không?”
  3. Độ tin cậy và hàng đợi. Mỗi lần trích xuất đều có điểm tin cậy; các dòng độ tin cậy thấp đi vào hàng đợi rà soát của con người thay vì vào database. Hàng đợi chính là thứ làm “thất bại âm thầm” trở nên ồn ào — và các thất bại có thể retry ánh xạ sang tài liệu tham chiếu error codes.
  4. PII ở cả hai đầu. Che dữ liệu trước khi trích xuất nếu có thể, quét sau khi trích xuất — xử lý dữ liệu cá nhân là yêu cầu tuân thủ, không phải điểm cộng của pipeline, và checklist quyền riêng tư dữ liệu chuẩn được áp dụng.

Cách mở rộng quy mô và cắt giảm chi phí

Điểm chính: chi phí mỗi 1,000 tài liệu là một con số thiết kế — phân tầng theo độ phức tạp tài liệu và batching theo khối lượng thường cắt giảm một nửa hoặc hơn.

Mô hình chi phí: mỗi 1,000 tài liệu = chi phí parsing (nếu có) + token model × giá model. Các đòn bẩy:

  1. Phân tầng theo độ phức tạp tài liệu. Tài liệu kỹ thuật số sạch chạy trên model giá rẻ; tài liệu quét hoặc nhiều bảng chạy trên đường đắt tiền. Hầu hết pipeline có 70-80% tài liệu sạch, nghĩa là 70-80% khối lượng trả mức giá rẻ — custom routing khiến quyết định theo từng tài liệu trở nên cơ học.
  2. Batch phần tồn đọng. Các kho tài liệu lịch sử là khối lượng công việc batch hoàn hảo — chấp nhận độ trễ, khối lượng lớn, và mô hình chiết khấu batch trong loạt bài này áp dụng mức giảm 50% nguyên vẹn.
  3. Cache template. Cùng nhà cung cấp, cùng template = cùng prompt prefix. Prefix ổn định đạt mức giá cache, điều này quan trọng với trích xuất hơn hầu hết mọi thứ khác, vì template lặp lại hàng nghìn lần.
  4. Tự xây hay mua parser. Nhà cung cấp tính phí theo trang; mã nguồn mở tính phí theo giờ GPU. Phân tích TCO trong loạt bài này cho thấy cấu trúc: dịch vụ quản lý thắng dưới ngưỡng khối lượng, mã nguồn mở thắng trên ngưỡng, và ngưỡng phụ thuộc vào mức độ sẵn sàng vận hành của bạn.

Những sai lầm phổ biến âm thầm làm hỏng dữ liệu

Điểm chính: bốn mô hình hỏng hóc âm thầm — từng mô hình đều tạo ra dữ liệu sai trông rất hợp lý.

  1. Schema không có xác thực. Schema là một mô tả, không phải một cổng chặn. Không có kiểm tra kiểu dữ liệu và quy tắc trường bắt buộc, trích xuất “ràng buộc schema” vẫn trả về trường rỗng được coi là dữ liệu.
  2. Bỏ qua OCR trên tài liệu quét. Văn bản hỗn độn vào, JSON rác ra — lỗi parser nằm ở thượng nguồn của model, và không prompt nào sửa được.
  3. Không theo dõi phiên bản model. Nâng cấp model làm thay đổi hành vi trích xuất; không có phiên bản ghim chặt và corpus hồi quy, “model tốt hơn” âm thầm trở thành “các trường bị dịch chuyển”. Hãy quản lý phiên bản chuỗi model và schema cùng nhau.
  4. Toàn tuyến đầu, mọi lúc. Tài liệu sạch chạy trên model flagship là cách đắt nhất để không cải thiện được độ chính xác — hãy phân tầng theo độ phức tạp, và dành khoản tiết kiệm cho hàng đợi rà soát.

Câu hỏi thường gặp

Tôi có thể trích xuất từ PDF chỉ với một LLM không?

PDF kỹ thuật số sạch, có. Tài liệu quét và bố cục phức tạp cần OCR hoặc một multimodal model trước — parser quyết định trần, và LLM trích xuất trong phạm vi đó.

Làm sao đo độ chính xác trích xuất một cách trung thực?

So khớp cấp trường (đúng trường, đúng kiểu, đúng giá trị) với một mẫu được gán nhãn thủ công, theo từng loại tài liệu — cộng thêm lỗi xác thực kiểu dữ liệu và trường bắt buộc như một thước đo riêng. So khớp “trông giống” tạo ra vấn đề sai lầm thầm lặng 3% mà hướng dẫn này tồn tại để ngăn chặn.

Trích xuất tốn bao nhiêu mỗi 1,000 tài liệu?

Chi phí parsing (nếu có) cộng token model theo tầng giá của bạn — model giá rẻ trên tài liệu sạch thấp hơn hẳn model flagship trên tài liệu quét. Phân tầng theo độ phức tạp và mức trung bình giảm mạnh; batch phần tồn đọng và nó giảm thêm một nửa.

Tôi nên thiết kế schema như thế nào?

Trường bắt buộc, enum và kiểu dữ liệu — được thực thi qua structured output, với trường bắt buộc bị thiếu được coi là lỗi. Schema là hợp đồng giữa tài liệu và database của bạn, và nó xứng đáng được rà soát ngang với cả hai.

Tôi có cần nhà cung cấp parsing, hay mã nguồn mở là đủ?

Hãy chạy bài kiểm tra ba chiều trên corpus của bạn. Nhà cung cấp dẫn đầu trên bố cục phức tạp; mã nguồn mở (Docling, Marker, các model chuyên trích xuất như NuExtract3) thắng về chi phí và kiểm soát ở khối lượng lớn. Ngưỡng TCO là có thật và đo lường được.

Làm sao xử lý PII trong trích xuất?

Che dữ liệu trước khi trích xuất nếu có thể, quét đầu ra sau đó, và giữ thời gian lưu trữ ở mức tối thiểu — các yêu cầu quyền riêng tư dữ liệu chuẩn áp dụng cho dữ liệu đã trích xuất y hệt như áp dụng cho tài liệu gốc.

Tóm tắt

Trích xuất dữ liệu bằng LLM là kỷ luật pipeline, không phải thuộc tính model: parse có chủ đích, định nghĩa schema như một hợp đồng, trích xuất trong phạm vi đó, và xác thực mọi thứ để thất bại trở nên ồn ào. Benchmark parser trên tài liệu của bạn trước model, phân tầng theo độ phức tạp tài liệu, batch phần tồn đọng, và coi hàng đợi rà soát là một tính năng. Làm đúng, trích xuất là workload khối lượng lớn đáng tin cậy nhất trong stack LLM; làm sai, nó là dữ liệu sai trông hợp lý đang bơm vào database của bạn.

Chạy 100 trang qua pipeline trước khi bạn tranh luận với benchmark. Lấy API key TokSpan của bạn — $5 tín dụng miễn phí để chạy mẫu (quickstart) — và xem chi phí mỗi tài liệu trên chính hóa đơn của bạn.