วิธีการสร้างตัวแทนประมวลผลใบแจ้งหนี้อัตโนมัติโดยใช้ AI แบบโอเพนซอร์ส

ระบบประมวลผลใบแจ้งหนี้อัตโนมัติไม่จำเป็นต้องเริ่มต้นจากการเป็นระบบ AI อัตโนมัติขนาดใหญ่ สำหรับเวอร์ชันแรกที่ใช้งานได้จริง ลองนึกถึงตัวแทนในฐานะเวิร์กโฟลว์ซอฟต์แวร์ที่มีการควบคุม ซึ่งรับใบแจ้งหนี้ เรียกใช้เอกสารและเครื่องมือ AI ที่ถูกต้อง ตรวจสอบความถูกต้องของผลลัพธ์ ตัดสินใจว่าต้องให้มนุษย์ตรวจสอบหรือไม่ และหลังจากนั้นจึงบันทึกหรือส่งออกข้อมูลที่ได้รับการอนุมัติ

ความแตกต่างนี้มีความสำคัญในด้านการเงิน แบบจำลองภาษาอาจช่วยเปลี่ยนรูปแบบใบแจ้งหนี้ที่ยุ่งเหยิงให้เป็นช่องข้อมูลที่มีโครงสร้าง แต่ไม่ควรเป็นสิ่งเดียวที่ตัดสินว่าใบแจ้งหนี้ถูกต้องหรือปลอดภัยที่จะบันทึกหรือไม่ การออกแบบที่เป็นมิตรกับผู้เริ่มต้นในคู่มือนี้ทำให้การดึงข้อมูลเป็นแบบสุ่ม และการตรวจสอบทางบัญชีที่สำคัญเป็นแบบสุ่ม

เมื่อเสร็จสิ้นกระบวนการ คุณจะมีต้นแบบระบบภายในองค์กรที่สามารถรับใบแจ้งหนี้ในรูปแบบ PDF หรือรูปภาพ ดึงข้อมูลต่างๆ เช่น ผู้ขาย หมายเลขใบแจ้งหนี้ วันที่ สกุลเงิน ยอดรวม และรายการสินค้า ตรวจสอบความถูกต้องของข้อมูลเหล่านั้นตามกฎเกณฑ์ ส่งต่อเอกสารที่น่าสงสัยไปยังฝ่ายตรวจสอบ บันทึกประวัติการตรวจสอบ และเปิดเผยกระบวนการผ่าน API

คุณต้องเข้าใจอะไรบ้างก่อนเริ่มต้น?

มีคำศัพท์สำคัญ 4 คำที่ควรรู้:

• OCR (การรู้จำอักขระด้วยแสง)แปลงข้อความที่มองเห็นได้ในภาพหรือเอกสารสแกนให้เป็นข้อความที่เครื่องสามารถอ่านได้
• การวิเคราะห์เอกสารช่วยรักษาโครงสร้างได้มากกว่า OCR ทั่วไป เช่น ลำดับการอ่าน ตาราง หัวข้อ และส่วนต่างๆ ของเค้าโครง
• LLM (โมเดลภาษาขนาดใหญ่)สามารถแปลงข้อความในใบแจ้งหนี้ที่เปลี่ยนแปลงได้ให้เป็นโครงสร้าง JSON ที่สม่ำเสมอ
• การมีมนุษย์เข้ามาเกี่ยวข้องหมายความว่าระบบจะหยุดทำงานและขอให้บุคคลตรวจสอบกรณีที่ตรวจสอบไม่ผ่าน แทนที่จะแสร้งทำเป็นว่าทุกผลลัพธ์ถูกต้อง

ณ เดือนกันยายน 2026 มีโครงการโอเพนซอร์สหลายโครงการที่ได้รับการดูแลรักษาอย่างต่อเนื่องครอบคลุมเลเยอร์เหล่านี้Doclingรองรับ PDF, รูปภาพ, เอกสารสำนักงาน และรูปแบบเอกสารอื่นๆPaddleOCRให้บริการ OCR และไปป์ไลน์การทำความเข้าใจเอกสาร และเผยแพร่ภายใต้ Apache 2.0 และโครงการ Tesseract ได้บันทึกเวอร์ชัน 5.x ปัจจุบันไว้เป็นเอ็นจิ้น OCR โอเพนซอร์สในคู่มือ Tesseract อย่างเป็นทางการ

สำหรับการอนุมานโมเดลในเครื่องโลคอล เอกสารประกอบเซิร์ฟเวอร์ของ llama.cppอธิบายถึงเอนด์พอยต์ที่เข้ากันได้กับ OpenAI และเอาต์พุต JSON ที่มีข้อจำกัดตามสคีมา ซึ่งทำให้มีประโยชน์สำหรับบริการการดึงข้อมูล เนื่องจากคุณสามารถขอให้โมเดลที่โฮสต์ในเครื่องส่งคืนอ็อบเจ็กต์ที่กำหนดไว้แทนที่จะเป็นข้อความที่ไม่จำกัด

มีข้อควรระวังเรื่องลิขสิทธิ์ที่สำคัญอย่างหนึ่งคือ เครื่องมืออนุมานแบบโอเพนซอร์สไม่ได้หมายความว่าน้ำหนักโมเดลทุกตัวจะเป็นโอเพนซอร์สโดยอัตโนมัติ ตรวจสอบลิขสิทธิ์สำหรับจุดตรวจสอบโมเดลที่คุณนำไปใช้งาน โดยเฉพาะอย่างยิ่งสำหรับการใช้งานเชิงพาณิชย์

ผู้เริ่มต้นควรใช้ชุดโปรแกรมอะไร?

เอกสารอย่างเป็นทางการของ Pydantic อธิบายว่าโมเดลสืบทอดมาจากคลาสBaseModelหลัก ตรวจสอบความถูกต้องของข้อมูลที่เข้ามา และสามารถสร้าง JSON Schema ผ่านทางเมธอด `import` ได้model_json_schema()โปรดดูที่การตรวจสอบความถูกต้องของโมเดล Pydanticหากคุณต้องการการแยกสาขาที่มีสถานะถาวรในภายหลังเอกสารอ้างอิงของ LangGraphจะอธิบายถึงการสนับสนุนเอเจนต์ที่มีสถานะทำงานต่อเนื่องยาวนาน การคงอยู่ของข้อมูล และเวิร์กโฟลว์ที่มีมนุษย์เข้ามาเกี่ยวข้อง

ขั้นตอนที่ 1: ตั้งค่าโครงการและกำหนดเป้าหมายแรกที่ชัดเจน

อย่าเริ่มต้นด้วย “ระบบชำระเงินอัตโนมัติ” ให้เริ่มต้นด้วยประเภทเอกสารเดียวและสัญญาส่งออกเดียว MVP ที่ดีควรเป็น: ใบแจ้งหนี้ซัพพลายเออร์ภาษาอังกฤษ, การรับข้อมูลในรูปแบบ PDF หรือรูปภาพ, นิติบุคคลเดียว, ชุดสกุลเงินเดียว และไม่มีการดำเนินการชำระเงินอัตโนมัติ

mkdir invoice-agent
cd invoice-agent
python -m venv .venv

# Linux/macOS
source .venv/bin/activate

pip install docling pydantic fastapi uvicorn httpx python-multipart

ติดตั้งโปรแกรม OCR แยกต่างหากหากคุณต้องการ คู่มือการติดตั้งปัจจุบันของ Docling ใช้pip install docling; ส่วนเอกสารการติดตั้งปัจจุบันของ PaddleOCR แยกแพ็กเกจ OCR พื้นฐานออกจากกลุ่มการพึ่งพาการวิเคราะห์เอกสารและการดึงข้อมูลเสริม ให้ใช้คู่มือการติดตั้งของ Doclingหรือคู่มือการติดตั้ง PaddleOCR 3.xแทนการคัดลอกรายการการพึ่งพาแบบเก่า

ขั้นตอนที่ 2: แปลงใบแจ้งหนี้เป็นข้อมูลข้อความและรูปแบบ

ไฟล์ PDF ดิจิทัลดั้งเดิมอาจมีข้อความที่ใช้งานได้อยู่แล้ว ส่วนไฟล์ PDF ที่สแกนและรูปภาพจำเป็นต้องใช้ OCR โปรแกรมวิเคราะห์ข้อความของคุณควรซ่อนความแตกต่างนี้จากขั้นตอนอื่นๆ ในขั้นตอนถัดไป: ขั้นตอนต่อๆ ไปควรได้รับข้อความเอกสารที่เป็นมาตรฐาน รวมถึงข้อมูลเค้าโครงหรือตารางที่เป็นประโยชน์ใดๆ ด้วย

ตัวอย่างการแปลงไฟล์ Docling แบบง่ายๆ จะมีลักษณะดังนี้:

from docling.document_converter import DocumentConverter

converter = DocumentConverter()

def parse_document(path: str) -> str:
    result = converter.convert(path)
    return result.document.export_to_markdown()

คู่มือเริ่มต้นใช้งานฉบับย่ออย่างเป็นทางการของ Docling ใช้รูปแบบการแปลงแล้วส่งออกเช่นเดียวกัน สำหรับชุดข้อมูลที่มีการประมวลผล OCR สูง ให้ทดสอบ PaddleOCR หรือ Tesseract กับไฟล์สแกนของคุณเอง เอกสารโครงการของ PaddleOCR แนะนำให้ใช้ตระกูล PP-StructureV3 รุ่นใหม่กว่าสำหรับการวิเคราะห์เอกสาร ในขณะที่ Tesseract สามารถเรียกใช้งานได้จากบรรทัดคำสั่งหรือ API สำหรับการประมวลผล OCR ข้อความที่พิมพ์แล้ว

ขั้นตอนที่ 3: ตัดสินใจให้แน่ชัดว่าเอเจนต์ได้รับอนุญาตให้สร้างข้อมูลอะไรบ้าง

โครงสร้างการดึงข้อมูลเปรียบเสมือนสัญญาระหว่าง AI กับตรรกะทางบัญชี หลีกเลี่ยงการสร้างโครงสร้างที่ครอบคลุมทุกอย่างที่อาจปรากฏในใบแจ้งหนี้ เริ่มต้นด้วยฟิลด์ที่คุณสามารถตรวจสอบความถูกต้องได้

from datetime import date
from decimal import Decimal
from pydantic import BaseModel, Field, ConfigDict

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

class Invoice(BaseModel):
    model_config = ConfigDict(extra="forbid")

    vendor_name: str
    invoice_number: str
    invoice_date: date
    due_date: date | None = None
    currency: str = Field(min_length=3, max_length=3)
    subtotal: Decimal | None = None
    tax: Decimal | None = None
    total: Decimal
    line_items: list[LineItem] = []

extra="forbid"สิ่งนี้มีประโยชน์ในบริบทนี้ เนื่องจากฟิลด์ LLM ที่ไม่คาดคิดไม่ควรปรากฏเป็นส่วนหนึ่งของบันทึกบัญชีของคุณโดยไม่แจ้งให้ทราบล่วงหน้า โปรดทราบด้วยว่าการตรวจสอบความถูกต้องของ Pydantic ยืนยันโครงสร้างและประเภทเท่านั้น ไม่ได้พิสูจน์ว่าผู้ขายหรือจำนวนเงินที่ดึงออกมาตรงกับภาพใบแจ้งหนี้

ขั้นตอนที่ 4: ใช้โมเดลภายในเครื่องเพื่อแปลงข้อความในเอกสารให้เป็น JSON ที่มีโครงสร้าง

เรียกใช้โมเดลคำสั่งที่เหมาะสมเบื้องหลังเซิร์ฟเวอร์ HTTP ของ llama.cpp ขนาดของโมเดลที่แน่นอนขึ้นอยู่กับฮาร์ดแวร์และความซับซ้อนของใบแจ้งหนี้ของคุณ อย่าคิดว่าโมเดลขนาดใหญ่จะดีกว่าเสมอไป ให้ทดสอบความถูกต้องของฟิลด์ ความหน่วง และหน่วยความจำบนชุดใบแจ้งหนี้ของคุณเอง

ปัจจุบัน llama.cpp รองรับการตอบกลับ JSON ที่มีข้อจำกัดตามสคีมา คุณสามารถดึงสคีมานั้นจาก Pydantic และส่งไปพร้อมกับคำขอแยกข้อมูลได้:

import json
import httpx

def extract_invoice(document_text: str) -> Invoice:
    schema = Invoice.model_json_schema()

    prompt = f"""
Extract one supplier invoice from the text below.
Do not invent values. If an optional field is absent, use null.
Currency must be a three-letter code.
Return only data that fits the required schema.

DOCUMENT:
{document_text}
"""

    payload = {
        "model": "local-model",
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0,
        "response_format": {
            "type": "json_schema",
            "schema": schema
        }
    }

    r = httpx.post(
        "http://127.0.0.1:8080/v1/chat/completions",
        json=payload,
        timeout=120
    )
    r.raise_for_status()

    content = r.json()["choices"][0]["message"]["content"]
    return Invoice.model_validate_json(content)

การสร้าง JSON โดยใช้ Schema-constrained ช่วยให้ได้โครงสร้างที่ถูกต้อง แต่ไม่รับประกันความถูกต้องทางความหมาย JSON ที่ถูกต้องสมบูรณ์แบบก็อาจยังแสดงผลรวมที่ไม่ถูกต้องได้ นั่นคือเหตุผลที่ขั้นตอนต่อไปมีความจำเป็น

ขั้นตอนที่ 5: เพิ่มการตรวจสอบทางบัญชีแบบกำหนดค่าได้และกฎการทบทวน

อย่าถาม LLM ว่า “คุณมั่นใจไหม?” แล้วเชื่อคำตอบนั้น ความมั่นใจในแบบจำลองที่รายงานด้วยตนเองไม่ใช่ตัวควบคุมที่ได้รับการสอบเทียบแล้ว สร้างการตรวจสอบที่สามารถคำนวณใหม่ได้จากข้อมูลที่ดึงมาและจากระบบของคุณ

กฎพื้นฐานที่มีประโยชน์ ได้แก่:

• ช่องข้อมูลที่จำเป็นมีอยู่ครบถ้วน;
• หมายเลขใบแจ้งหนี้ยังไม่ได้รับการบันทึกไว้สำหรับผู้ขายรายเดียวกัน
• อนุญาตให้ใช้สกุลเงินนี้สำหรับผู้ขายหรือหน่วยงานนั้น
• จำนวนเงินในแต่ละรายการรวมกันได้ประมาณเท่ากับยอดรวมย่อย
• ยอดรวมย่อยบวกภาษีโดยประมาณเท่ากับยอดรวมทั้งหมด
• วันที่ออกใบแจ้งหนี้และวันครบกำหนดชำระมีความสมเหตุสมผล
• ผู้ขายมีอยู่ในข้อมูลหลักของผู้ขายของคุณ หรือถูกส่งต่อไปยังขั้นตอนการลงทะเบียนใช้งาน
• หมายเลขอ้างอิงใบสั่งซื้อจะตรงกันเมื่อจำเป็นต้องมีการตรวจสอบความถูกต้องของใบสั่งซื้อ

from decimal import Decimal

def validate_business_rules(inv: Invoice) -> list[str]:
    errors = []

    if inv.subtotal is not None and inv.tax is not None:
        expected = inv.subtotal + inv.tax
        if abs(expected - inv.total) > Decimal("0.02"):
            errors.append("subtotal_plus_tax_does_not_match_total")

    line_sum = sum((x.amount for x in inv.line_items), Decimal("0"))
    if inv.subtotal is not None and abs(line_sum - inv.subtotal) > Decimal("0.02"):
        errors.append("line_items_do_not_match_subtotal")

    if inv.due_date and inv.due_date < inv.invoice_date:
        errors.append("due_date_before_invoice_date")

    return errors

ส่งการตรวจสอบที่ไม่ผ่านทั้งหมดไปยังคิวตรวจสอบ สำหรับการใช้งานครั้งแรก ควรส่ง ใบแจ้งหนี้ ทั้งหมดไปตรวจสอบในขณะที่คุณวัดคุณภาพการดึงข้อมูล เกณฑ์การทำงานอัตโนมัติควรมาจากหลักฐานที่รวบรวมได้จากใบแจ้งหนี้ที่คุณติดป้ายกำกับเอง ไม่ใช่จากเปอร์เซ็นต์ทั่วไปที่คัดลอกมาจากระบบอื่น

ขั้นตอนที่ 6: ห่อหุ้มโปรเซสเซอร์ด้วย API ขนาดเล็ก

API ช่วยให้แบบฟอร์มการอัปโหลด, ตัวจัดการอีเมล, ตัวตรวจสอบโฟลเดอร์ที่ใช้ร่วมกัน หรือการผสานรวมระบบบัญชี สามารถเรียกใช้ฟังก์ชันการประมวลผลเดียวกันได้ คู่มือการอัปโหลดไฟล์อย่างเป็นทางการของ FastAPI แนะนำให้UploadFileใช้ไฟล์แบบ Spooled สำหรับไฟล์ที่อัปโหลด และระบุว่าเหมาะสมกว่าการโหลดไฟล์ขนาดใหญ่ลงในหน่วยความจำทั้งหมด

from pathlib import Path
from tempfile import NamedTemporaryFile
from fastapi import FastAPI, UploadFile, HTTPException

app = FastAPI()

@app.post("/invoices")
async def process_upload(file: UploadFile):
    if file.content_type not in {
        "application/pdf",
        "image/png",
        "image/jpeg"
    }:
        raise HTTPException(415, "Unsupported file type")

    suffix = Path(file.filename or "").suffix

    with NamedTemporaryFile(suffix=suffix, delete=False) as tmp:
        tmp.write(await file.read())
        path = tmp.name

    result = process_invoice(path)
    return result

โปรดดู เอกสารประกอบไฟล์คำขอ FastAPIฉบับปัจจุบันสำหรับรูปแบบการอัปโหลดที่รองรับ ในการใช้งานจริง ควรบังคับใช้ข้อจำกัดขนาดไฟล์ การสแกนหามัลแวร์ในกรณีที่เหมาะสม ผู้เรียกใช้ที่ได้รับการรับรอง รหัสคำขอ และการล้างไฟล์ชั่วคราวอย่างปลอดภัยด้วย

ขั้นตอนที่ 7: จัดเก็บหลักฐานต้นฉบับ ผลลัพธ์ที่ปรับให้เป็นมาตรฐาน และเหตุการณ์การตรวจสอบ

อย่าเก็บเฉพาะไฟล์ JSON สุดท้ายเท่านั้น ควรเก็บหลักฐานให้เพียงพอเพื่อใช้ในการวิเคราะห์เหตุการณ์ที่เกิดขึ้น เช่น ข้อมูลระบุตัวตนของไฟล์ต้นฉบับ แฮช เวอร์ชันของตัวแยกวิเคราะห์ ตัวระบุโมเดล เวอร์ชันของพรอมต์ JSON ที่แยกออกมา ผลการตรวจสอบความถูกต้อง การตัดสินใจตรวจสอบ เวลาที่บันทึก และผู้ใช้หรือบริการที่อนุมัติการเปลี่ยนแปลง

ต้นแบบอย่างง่ายสามารถใช้ SQLite ได้ ส่วนบริการที่มีผู้ใช้หลายคนสามารถใช้ PostgreSQL พร้อมข้อจำกัดเรื่องความซ้ำซ้อนและคีย์ต่างประเทศ เอกสารปัจจุบันของ PostgreSQL ครอบคลุมถึงข้อจำกัดของตารางซึ่งมีประโยชน์สำหรับการปกป้องคีย์และความสัมพันธ์โดยไม่ขึ้นอยู่กับไปป์ไลน์ AI

CREATE TABLE invoices (
    id BIGSERIAL PRIMARY KEY,
    vendor_id BIGINT NOT NULL,
    invoice_number TEXT NOT NULL,
    invoice_date DATE NOT NULL,
    currency CHAR(3) NOT NULL,
    total NUMERIC(18,2) NOT NULL,
    status TEXT NOT NULL,
    source_sha256 TEXT NOT NULL,
    extracted_json JSONB NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    UNIQUE (vendor_id, invoice_number)
);

แฮชต้นทางช่วยให้คุณตรวจจับการส่งซ้ำโดยไม่ได้ตั้งใจได้อีกวิธีหนึ่ง ควรควบคุมสิทธิ์การเข้าถึงไฟล์ให้เข้มงวดกว่าบันทึกการใช้งานทั่วไป เนื่องจากใบแจ้งหนี้มักมีที่อยู่ รายละเอียดธนาคาร หมายเลขประจำตัวผู้เสียภาษี และข้อมูลสำคัญทางธุรกิจอื่นๆ

ขั้นตอนที่ 8: ทดสอบด้วยข้อมูลใบแจ้งหนี้จริงก่อนที่จะดำเนินการอัตโนมัติในขั้นตอนถัดไป

ต้นแบบที่ใช้งานได้กับไฟล์ PDF ที่สะอาด 5 ไฟล์นั้นยังไม่พร้อมสำหรับการใช้งานจริง สร้างชุดข้อมูลประเมินผลที่มีการระบุป้ายกำกับซึ่งแสดงถึงข้อมูลที่คุณได้รับจริง เช่น ผู้ขายที่แตกต่างกัน การสแกน หน้าที่หมุน ฟอนต์ขนาดเล็ก ใบแจ้งหนี้หลายหน้า ส่วนลด รายการติดลบ ภาษี ค่าจัดส่ง สกุลเงินหลายสกุล ใบสั่งซื้อที่หายไป และการส่งเอกสารซ้ำ

ติดตามตัวชี้วัดระดับฟิลด์แยกกัน “ความถูกต้องของใบแจ้งหนี้” อาจปกปิดข้อเท็จจริงที่ว่าชื่อผู้ขายนั้นง่าย แต่ปริมาณสินค้าในแต่ละรายการนั้นไม่น่าเชื่อถือ อย่างน้อยที่สุด ควรวัด:

• ความถูกต้องแม่นยำในการจับคู่หมายเลขใบแจ้งหนี้ สกุลเงิน และวันที่
• ความแม่นยำของค่าความคลาดเคลื่อนเชิงตัวเลขสำหรับยอดรวมย่อย ภาษี และยอดรวมทั้งหมด;
• ความแม่นยำและอัตราการเรียกคืนข้อมูลของแต่ละรายการ หากรายการเหล่านั้นมีความสำคัญในขั้นตอนต่อไป
• เปอร์เซ็นต์ที่ส่งต่อไปยังการตรวจสอบโดยมนุษย์
• อัตราการอนุมัติอัตโนมัติที่ไม่ถูกต้อง;
• ความล่าช้าในการประมวลผลและอัตราความล้มเหลว
• ความแม่นยำในการตรวจจับข้อมูลซ้ำ

บันทึกข้อผิดพลาดเป็นกรณีทดสอบ ทุกครั้งที่คุณแก้ไขกฎการแยกวิเคราะห์ ข้อความแจ้งเตือน โครงสร้างข้อมูล หรือโมเดล ให้รันชุดการประเมินทั้งหมดอีกครั้ง วิธีนี้จะช่วยป้องกันไม่ให้การปรับปรุงของผู้จำหน่ายรายหนึ่งไปทำให้โครงสร้างของผู้จำหน่ายรายอื่นเสียหายโดยไม่รู้ตัว

ตัวแทนควรตัดสินใจอย่างไรเกี่ยวกับสิ่งที่จะเกิดขึ้นต่อไป?

ระบุสถานะของเครื่องสถานะให้ชัดเจน ในตอนแรก "เอเจนต์" อาจเป็นเพียงฟังก์ชัน Python ธรรมดาก็ได้:

def process_invoice(path: str) -> dict:
    text = parse_document(path)
    invoice = extract_invoice(text)
    errors = validate_business_rules(invoice)

    if errors:
        status = "needs_review"
    else:
        status = "validated"

    record_id = save_invoice(
        source_path=path,
        invoice=invoice,
        validation_errors=errors,
        status=status,
    )

    return {
        "id": record_id,
        "status": status,
        "invoice": invoice.model_dump(mode="json"),
        "validation_errors": errors,
    }

นี่ก็เหมือนเอเจนต์อยู่แล้ว เพราะมันประสานงานเครื่องมือและเลือกสาขา คุณไม่จำเป็นต้องใช้ LLM เพื่อเลือกขั้นตอนต่อไปทุกขั้นตอน เพิ่ม LangGraph หรือเฟรมเวิร์กการจัดการกระบวนการทำงานอื่นๆ เมื่อต้องการการตรวจสอบหลายขั้นตอนแบบถาวร การลองใหม่ การเรียกกลับแบบอะซิงโครนัส หรือเครื่องมือเฉพาะทางหลายอย่างที่ลำดับการทำงานเปลี่ยนแปลงไปตามแต่ละกรณี

ผู้เริ่มต้นควรหลีกเลี่ยงข้อผิดพลาดอะไรบ้าง?

การปล่อยให้ LLM ทำหน้าที่เป็นตัวควบคุมทางบัญชี

แบบจำลองควรดึงข้อมูลและทำให้เป็นมาตรฐาน โค้ดและข้อมูลจากระบบที่เชื่อถือได้ควรได้รับการตรวจสอบ การคำนวณทางคณิตศาสตร์ การตรวจสอบข้อมูลซ้ำ สถานะผู้ขาย การจับคู่ใบสั่งซื้อ และขีดจำกัดการอนุมัติ ควรอยู่ในตรรกะเชิงกำหนด

ทิ้งเอกสารต้นฉบับหลังจากแยกข้อมูลเสร็จแล้ว

เก็บใบแจ้งหนี้ต้นฉบับหรือเอกสารอ้างอิงที่ควบคุมได้ไว้ ผู้ตรวจสอบต้องการหลักฐาน และคุณจำเป็นต้องมีวิธีการจำลองข้อผิดพลาดหลังจากอัปเกรดโมเดลหรือตัวแยกวิเคราะห์

การใช้พรอมต์เดียวโดยไม่มีเวอร์ชัน

ควรบันทึกเวอร์ชันและตัวระบุรุ่นของข้อความแจ้งเตือนไว้กับใบแจ้งหนี้แต่ละฉบับที่ประมวลผล มิเช่นนั้น คุณจะไม่สามารถอธิบายได้ว่าทำไมใบแจ้งหนี้สองฉบับที่ประมวลผลห่างกันหลายเดือนจึงมีพฤติกรรมแตกต่างกัน

โพสต์ผลลัพธ์ที่ตรงตาม Schema โดยอัตโนมัติทุกรายการ

ความถูกต้องของไฟล์ JSON ไม่ใช่ความถูกต้องของใบแจ้งหนี้ เริ่มต้นด้วยการตรวจสอบโดยมนุษย์ก่อน จากนั้นจึงค่อยใช้ระบบอัตโนมัติเฉพาะในกรณีที่มีความเสี่ยงต่ำ หลังจากที่การประเมินแสดงให้เห็นถึงประสิทธิภาพที่ยอมรับได้แล้ว

ไม่สนใจใบอนุญาตโมเดลและข้อมูล

ไลบรารีและน้ำหนักโมเดลอาจมีใบอนุญาตที่แตกต่างกัน PaddleOCR และ Tesseract เผยแพร่ใบอนุญาตแบบโอเพนซอร์ส ในขณะที่ใบอนุญาตของโมเดลที่คุณใช้งานผ่าน llama.cpp ขึ้นอยู่กับจุดตรวจสอบเฉพาะนั้นๆ โปรดยืนยันก่อนนำไปใช้งาน

สร้าง UI ก่อนที่จะพิสูจน์คุณภาพการสกัด

แดชบอร์ดที่ดูดีอย่างเดียวไม่สามารถชดเชยข้อมูลที่ไม่ถูกต้องได้ ควรทดสอบการแยกวิเคราะห์เอกสาร การดึงข้อมูลโครงสร้าง และการตรวจสอบความถูกต้องก่อน จากนั้นค่อยเพิ่มส่วนติดต่อผู้ตรวจสอบหลังจากที่คุณทราบแล้วว่าผู้ตรวจสอบต้องการเห็นอะไรบ้าง

คุณควรใช้ OCR อย่างเดียว, โมเดลจัดวาง หรือ LLM เมื่อใด?

เอกสาร LayoutLMv3ปัจจุบันของ Hugging Face อธิบายถึงโมเดล AI สำหรับเอกสารที่ผสมผสานข้อมูลข้อความและข้อมูลการจัดวางภาพ ในทำนองเดียวกัน เอกสาร PP-StructureV3 ของ PaddleOCR ก็เน้นที่การจัดวาง ตาราง และการวิเคราะห์เอกสารที่มีโครงสร้าง สิ่งเหล่านี้เป็นทางเลือกเมื่อข้อความธรรมดาและ LLM ไม่เพียงพอ

เส้นทางที่เหมาะสมจากต้นแบบไปสู่การผลิตคืออะไร?

ดำเนินการเป็นขั้นตอน ขั้นแรก ให้ทดสอบในเครื่องคอมพิวเตอร์ของคุณเอง โดยใช้โฟลเดอร์ที่มีป้ายกำกับใบแจ้งหนี้ ขั้นที่สอง เพิ่ม API และพื้นที่จัดเก็บข้อมูลถาวร ขั้นที่สาม เพิ่มระบบตรวจสอบโดยมนุษย์ ขั้นที่สี่ ผสานรวมการค้นหาข้อมูลแบบอ่านอย่างเดียว เช่น ข้อมูลหลักของผู้ขาย หรือใบสั่งซื้อ ขั้นที่ห้า อนุญาตให้ส่งออกข้อมูลไปยังพื้นที่จัดเก็บชั่วคราวสำหรับการบัญชีได้ภายใต้การควบคุม หลังจากที่การตรวจสอบพิสูจน์แล้วว่าการควบคุมมีประสิทธิภาพแล้ว จึงค่อยพิจารณาการบันทึกบัญชีอัตโนมัติสำหรับกรณีที่มีความเสี่ยงต่ำและกำหนดไว้อย่างชัดเจน

ในทุกขั้นตอน ต้องรักษาไว้ซึ่งสามสิ่งต่อไปนี้: หลักฐาน (เอกสารต้นฉบับและแหล่งข้อมูลที่ดึงออกมา), ความแน่นอน (กฎทางธุรกิจที่สามารถเรียกใช้ซ้ำได้) และความสามารถในการตรวจสอบย้อนกลับ (ตัวแยกวิเคราะห์ โมเดล ข้อความแจ้งเตือน และผู้ตรวจสอบใดที่สร้างบันทึกสุดท้าย)

รายการตรวจสอบขั้นสุดท้าย

• โปรแกรมวิเคราะห์ใบแจ้งหนี้ใช้งานได้ทั้งกับไฟล์ PDF ดิจิทัลและไฟล์สแกนที่คุณได้รับจริง
• ผลลัพธ์ของการดึงข้อมูลถูกจำกัดให้อยู่ภายในสคีมา Pydantic ที่มีการกำหนดเวอร์ชันไว้
• แบบจำลองนี้ไม่อนุญาตให้สร้างค่าที่หายไปขึ้นมาเอง
• ยอดรวม วันที่ รายการซ้ำ ข้อมูลผู้ขาย และกฎ PO จะได้รับการตรวจสอบความถูกต้องภายนอกระบบ LLM
• หากกฎใดไม่ผ่าน จะนำไปสู่สถานะการตรวจสอบโดยมนุษย์แทนที่จะเป็นการแก้ไขแบบเงียบๆ
• ข้อมูลเอกสารต้นฉบับ, แฮชแหล่งที่มา, โมเดล, เวอร์ชันของพรอมต์ และผลการตรวจสอบความถูกต้องจะถูกบันทึกไว้
• API นี้จำกัดประเภทและขนาดของไฟล์ และต้องมีการตรวจสอบสิทธิ์ก่อนใช้งานจริง
• ชุดทดสอบของคุณประกอบด้วยรูปแบบการจัดวางที่หลากหลายและกรณีพิเศษต่างๆ
• ระบบได้ตรวจสอบใบอนุญาตโมเดลและไลบรารีสำหรับการใช้งานที่คุณต้องการแล้ว
• การบันทึกบัญชีปลายทางจะค่อยๆ ถูกนำมาใช้และยังคงสามารถตรวจสอบได้

หากมีการควบคุมเหล่านั้นอย่างเหมาะสม คุณจะได้มากกว่าแค่การสาธิต OCR: คุณจะมีรากฐานของระบบประมวลผลใบแจ้งหนี้ที่เชื่อถือได้ ส่วนประกอบโอเพนซอร์สอาจเปลี่ยนแปลงไปตามกาลเวลา แต่สถาปัตยกรรมยังคงทนทาน—วิเคราะห์หลักฐาน ดึงข้อมูลเข้าสู่โครงสร้าง ตรวจสอบความถูกต้องด้วยโค้ด ส่งต่อความไม่แน่นอนไปยังบุคคล และบันทึกทุกการตัดสินใจ