Trích xuất dữ liệu hóa đơn: deep learning so với machine learning so với LLM (hướng dẫn 2026)

Năm năm trước, trích xuất dữ liệu có cấu trúc từ hóa đơn đồng nghĩa với một quy trình deep learning: một bước OCR, một mô hình nhận biết bố cục (LayoutLM, Donut) được tinh chỉnh trên hàng nghìn tài liệu gắn nhãn thủ công, cùng gánh nặng bảo trì mỗi khi nhà cung cấp thay đổi mẫu. Năm 2026, toàn bộ quy trình thu gọn thành một lần gọi API vision-LLM: đưa ảnh vào, nhận JSON đã xác thực theo schema — không dữ liệu huấn luyện, không mô hình lưu trữ, và bố cục mới được xử lý zero-shot. Hướng dẫn này từ Kunavo — một gateway độc lập, tương thích với OpenAI, đến các vision model mà mô hình này sử dụng — trình bày toàn bộ cách triển khai, chi phí trên mỗi hóa đơn được đo theo bảng giá công bố của chúng tôi, và cách duy trì độ chính xác ở cấp sản xuất.

So sánh các phương pháp trích xuất hóa đơn: quy tắc, machine learning, deep learning, LLM

Bốn thế hệ kỹ thuật đã được dùng để lấy dữ liệu có cấu trúc từ hóa đơn. Việc đặt chúng cạnh nhau là đáng giá, vì sự đánh đổi từng quyết định lựa chọn giữa chúng trong hai thập kỷ — mua độ chính xác bằng dữ liệu đã gắn nhãn — là điều không còn áp dụng.

Ba phương pháp đầu tiên đều có chung một đặc điểm: độ chính xác được mua bằng dữ liệu đã gắn nhãn. Mỗi mẫu nhà cung cấp, mỗi đặc trưng CRF, mỗi lần tinh chỉnh LayoutLM đều là một dự án chú thích. Vision LLM đã trả chi phí đó trong quá trình tiền huấn luyện, nên chi phí biên cho một bố cục mới bằng không. Đó là toàn bộ sự chuyển dịch — không phải các phương pháp cũ ngừng hoạt động, mà là thứ chúng từng tiêu ngân sách đã trở nên miễn phí.

Deep learning tinh chỉnh so với vision LLM, chi tiết

Bộ trích xuất tinh chỉnh vẫn có thể thắng trên một bố cục cố định duy nhất có khối lượng lớn, nhưng với phần lớn hóa đơn trong thực tế — nhiều nhà cung cấp, ngôn ngữ và chất lượng bản quét khác nhau — vision LLM zero-shot chính xác hơn trong thực tế và rẻ hơn rất nhiều để vận hành. Xem thêm các mô hình cho loại khối lượng công việc này trong trường hợp sử dụng trích xuất dữ liệu.

Mô hình hoàn chỉnh: ảnh → JSON đã xác thực theo schema

Mọi thứ bên dưới đều chạy qua endpoint tương thích với OpenAI của Kunavo — trỏ base_url đến https://api.kunavo.com/v1 và cùng một đoạn mã có thể gọi Claude hoặc GPT chỉ bằng cách thay đổi một chuỗi:

from openai import OpenAI
import base64, json

client = OpenAI(
    base_url="https://api.kunavo.com/v1",
    api_key="sk-kn-...",
)

SCHEMA = {
    "name": "invoice",
    "schema": {
        "type": "object",
        "properties": {
            "vendor_name":    {"type": "string"},
            "vendor_tax_id":  {"type": ["string", "null"]},
            "invoice_number": {"type": "string"},
            "invoice_date":   {"type": "string", "description": "ISO 8601"},
            "due_date":       {"type": ["string", "null"]},
            "currency":       {"type": "string", "description": "ISO 4217"},
            "line_items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "description": {"type": "string"},
                        "quantity":    {"type": "number"},
                        "unit_price":  {"type": "number"},
                        "amount":      {"type": "number"},
                    },
                    "required": ["description", "amount"],
                },
            },
            "subtotal":  {"type": ["number", "null"]},
            "tax":       {"type": ["number", "null"]},
            "total":     {"type": "number"},
        },
        "required": ["vendor_name", "invoice_number", "invoice_date",
                     "currency", "line_items", "total"],
    },
}

def extract(path: str) -> dict:
    image_b64 = base64.b64encode(open(path, "rb").read()).decode()
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",   # the cheapest capable model for clean invoices
        response_format={"type": "json_schema", "json_schema": SCHEMA},
        messages=[
            {"role": "system", "content":
                "Extract the invoice into the schema. Copy values exactly as "
                "printed; use null when a field is absent. Never invent data."},
            {"role": "user", "content": [
                {"type": "image_url",
                 "image_url": {"url": f"data:image/png;base64,{image_b64}"}},
            ]},
        ],
    )
    return json.loads(resp.choices[0].message.content)

inv = extract("invoice_0231.png")

# Cheap arithmetic guardrail: reject when the line items don't add up.
delta = abs(sum(li["amount"] for li in inv["line_items"])
            + (inv.get("tax") or 0) - inv["total"])
if delta > 0.02:
    raise ValueError(f"line items disagree with total by {delta:.2f}")

print(inv["vendor_name"], inv["total"], inv["currency"])

Ba chi tiết đảm nhiệm phần lớn công việc: JSON schema trong response_format (trên Claude, mô hình không thể phát ra bất kỳ thứ gì khác — xem ghi chú về GPT trong tài liệu tham khảo được liên kết bên dưới), quy tắc system prompt “sao chép giá trị chính xác; null khi không có; không bao giờ tự bịa” (loại bỏ mã số thuế bị bịa), và guardrail số học — các mục hàng + thuế phải bằng tổng cộng, nếu không tài liệu được chuyển sang mô hình mạnh hơn hoặc con người. Xem tài liệu tham khảo chat completions để biết response_format áp dụng điều gì trên từng họ mô hình.

Cùng schema dưới dạng mô hình Pydantic có kiểu

Một dict JSON-schema thô phù hợp với một endpoint nhưng trở nên khó chịu khi có mười endpoint. Trong sản xuất, hầu hết đội ngũ định nghĩa schema một lần dưới dạng mô hình Pydantic rồi suy ra cả ràng buộc lẫn đối tượng đã phân tích từ đó, để bộ trích xuất và phần còn lại của codebase không bao giờ bất đồng về cấu trúc:

from pydantic import BaseModel, Field
from typing import Literal
from openai import OpenAI

client = OpenAI(base_url="https://api.kunavo.com/v1", api_key=KEY)

class LineItem(BaseModel):
    description: str
    quantity: float | None = None
    unit_price: float | None = None
    amount: float

class Invoice(BaseModel):
    vendor_name: str
    vendor_tax_id: str | None = None
    invoice_number: str
    invoice_date: str = Field(description="ISO 8601")
    currency: str = Field(description="ISO 4217")
    line_items: list[LineItem]
    tax: float | None = None
    total: float
    # A confidence field the model fills in itself is a cheap, surprisingly
    # reliable router: low self-reported confidence correlates well with the
    # documents a human should see.
    confidence: Literal["high", "medium", "low"]

resp = client.chat.completions.create(
    model="claude-haiku-4-5",
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "invoice", "schema": Invoice.model_json_schema()},
    },
    messages=[...],
)

invoice = Invoice.model_validate_json(resp.choices[0].message.content)

Có hai điều đáng sao chép ở đây. Các trường được định kiểu là float | None thay vì float cho mô hình một cách hợp lệ để nói “không có” — nếu không, một dòng thuế bị thiếu sẽ kéo mạnh mô hình về phía việc bịa ra số không. Và trường confidence tự báo cáo chỉ tốn ba token đầu ra nhưng định tuyến hiệu quả đáng ngạc nhiên; trường này không được hiệu chuẩn, nhưng “thấp” là tín hiệu đáng tin rằng con người nên xem xét.

Định tuyến hai tầng: hệ thống thực tế chạy gì

Dùng một mô hình cho mọi tài liệu là sai về mặt cấu trúc. Hóa đơn in rõ ràng — chiếm đại đa số — được xử lý bằng vision model rẻ nhất hiện có; phần khó (chữ viết tay, bản quét kém, bố cục bất thường) là nơi mô hình mạnh hơn xứng đáng với mức giá của nó. Hãy nâng cấp dựa trên lỗi xác thực, không dựa trên phỏng đoán:

CHEAP, STRONG = "claude-haiku-4-5", "claude-sonnet-5"

def valid(inv: dict) -> bool:
    """Arithmetic is the guardrail no confidence score replaces."""
    items = sum(li["amount"] for li in inv["line_items"])
    return abs(items + (inv.get("tax") or 0) - inv["total"]) <= 0.02

def extract_routed(path: str) -> tuple[dict, str]:
    inv = extract(path, model=CHEAP)
    if valid(inv) and inv.get("confidence") != "low":
        return inv, CHEAP

    # Escalate: same prompt, same schema, stronger model. Only the failures
    # pay the higher rate, which is what keeps the blended cost near the
    # cheap tier's.
    inv = extract(path, model=STRONG)
    if not valid(inv):
        raise NeedsHumanReview(path, inv)
    return inv, STRONG

# Blended cost at a 90/10 split, per 10,000 invoices:
#   9,000 x $0.00248 + 1,000 x $0.00497
#   = $27.29

Kiểm tra số học mới là phần thực sự tạo ra hiệu quả: đây là tín hiệu duy nhất độc lập với ý kiến tự đánh giá của mô hình. Một tài liệu có các mục hàng cộng lại bằng tổng đã nêu gần như không bao giờ sai theo cách quan trọng; tài liệu không vượt qua kiểm tra đáng để chuyển sang mô hình mạnh hơn hoặc con người, bất kể trường độ tin cậy nói gì.

Chi phí trên mỗi hóa đơn theo mô hình

Một hóa đơn một trang ≈ 1.800 token đầu vào (gửi dưới dạng ảnh) + ~350 token đầu ra JSON:

Mức giá được cập nhật trực tiếp từ trang giá (thấp hơn khoảng 30% so với giá niêm yết của nhà cung cấp), và các yêu cầu thất bại không bị tính phí. Với định tuyến hai tầng — mọi thứ chạy qua Haiku, các trường hợp thất bại kiểm tra số học được nâng cấp lên Sonnet — 10.000 hóa đơn/tháng thường có chi phí dưới $27,29.

Độ chính xác: danh sách kiểm tra đưa bạn lên sản xuất

1. Schema trước. Đánh dấu các trường thực sự bắt buộc là required, cho phép null ở mọi nơi khác — ép phải có giá trị đồng nghĩa với ép mô hình bịa.
2. Gửi ảnh, không gửi văn bản OCR. Bố cục mang ý nghĩa (cột, ô tổng); vision model đọc trực tiếp bố cục. Chỉ chuyển sang văn bản với PDF kỹ thuật số khi bạn có thể trích xuất một lớp văn bản sạch.
3. Xác thực số học trong code. Các mục hàng + thuế = tổng cộng phát hiện phần lớn lỗi trích xuất miễn phí.
4. Nâng cấp, đừng mù quáng thử lại. Các trường hợp thất bại được gửi đến Sonnet cùng lỗi xác thực trong prompt; các trường hợp vẫn thất bại được chuyển đến hàng đợi xử lý thủ công.
5. Few-shot các trường hợp biên thực sự. Hai hoặc ba ví dụ về bố cục tệ nhất của bạn (phiếu ghi có, đa tiền tệ) trong system prompt hiệu quả hơn mọi mức instruction tuning.

Ngoài hóa đơn

Mô hình bị ràng buộc bởi schema tương tự bao phủ biên lai, đơn mua hàng, phiếu giao hàng, biểu mẫu hải quan và sao kê ngân hàng — thay schema, giữ nguyên guardrail. Xem trường hợp sử dụng trích xuất dữ liệu có cấu trúc rộng hơn để biết các mô hình gần với RAG, hoặc hướng dẫn tối ưu hóa chi phí để biết chiến lược định tuyến khi khối lượng tăng. Một khóa Kunavo bao phủ mọi tầng mô hình được dùng ở đây — đăng ký miễn phí và tạo khóa để chạy nguyên đoạn mã.

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