วิธีอัตโนมัติการดึงข้อมูล PDF โดยใช้โมเดล AI ในเครื่องโดยไม่ต้องใช้ Cloud API

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

ความแตกต่างนี้มีความสำคัญหากเป้าหมายของคุณคือ “ไม่ใช้ Cloud API” คุณยังคงสามารถใช้ API ในเครื่อง บนคอมพิวเตอร์ของคุณเองได้ ตัวอย่างเช่น HTTP endpoint ของ Ollama บน localhost โดยไม่ต้องส่งเนื้อหาเอกสารไปยังบริการที่โฮสต์ไว้ Ollama ระบุว่าพรอมต์และคำตอบจะไม่ถูกส่งกลับไปยัง Ollama เมื่อโมเดลทำงานในเครื่อง และมีโหมดเฉพาะเครื่องที่ปิดใช้งานฟีเจอร์คลาวด์ Docling เช่นกัน โดยปิดใช้งานบริการระยะไกลเป็นค่าเริ่มต้น แม้ว่าไฟล์โมเดลอาจต้องดาวน์โหลดระหว่างการตั้งค่าหากคุณไม่ได้เตรียมไว้ล่วงหน้าสำหรับการใช้งานแบบออฟไลน์

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

คำแนะนำอย่างรวดเร็ว: เลือกไปป์ไลน์ตามประเภทเอกสาร

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

ขั้นตอนที่ 1: จำแนกประเภท PDF ก่อนเลือก OCR หรือ AI

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

เอกสารทางการของ PyMuPDF แสดงการดึงข้อความโดยตรงด้วย page.get_text() การทดสอบในเครื่องขั้นต่ำมีลักษณะดังนี้:

import pymupdf

def extract_native_text(pdf_path: str) -> str:
    pages = []
    with pymupdf.open(pdf_path) as doc:
        for page in doc:
            pages.append(page.get_text())
    return "\f".join(pages)

text = extract_native_text("invoice.pdf")
print(text[:1000])

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

เหมาะที่สุดสำหรับ: ใบแจ้งหนี้ ใบแจ้งยอด รายงาน และแบบฟอร์มที่การคัดลอก/วางข้อความทำงานได้ดีอยู่แล้ว และฟิลด์ต่างๆ ระบุได้ง่ายจากป้ายกำกับใกล้เคียง

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

การดำเนินการ: นำ PDF ตัวแทน 20–50 ไฟล์มาจำแนกเป็นกลุ่ม born-digital, scanned, mixed และ layout-heavy ไปป์ไลน์ของคุณควรกำหนดเส้นทางตามพฤติกรรมของเอกสาร ไม่ใช่เพียงตามนามสกุลไฟล์

ขั้นตอนที่ 2: ดึงข้อความในเครื่อง หรือใช้ OCR เฉพาะเมื่อจำเป็น

ตัวเลือก A: PyMuPDF สำหรับ PDF ดิจิทัลที่ชัดเจน

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

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

ตัวเลือก B: OCRmyPDF บวก Tesseract สำหรับหน้าที่สแกน

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

สำหรับเอกสารแบบผสมที่บางหน้ามีข้อความอยู่แล้ว เวอร์ชันปัจจุบันของ OCRmyPDF รองรับโหมด skip:

ocrmypdf --mode skip input.pdf searchable.pdf

เอกสารขั้นสูงของ OCRmyPDF อย่างเป็นทางการ อธิบายว่า --mode skip จะไม่แตะต้องหน้าที่มีข้อความอยู่แล้วและทำ OCR เฉพาะหน้าที่ต้องการ เอกสารเดียวกันอธิบาย redo สำหรับการแทนที่ OCR ที่ตรวจพบก่อนหน้า และ force สำหรับการเรนเดอร์เป็นภาพและทำ OCR เนื้อหาทั้งหมด ใช้ force อย่างระมัดระวังเพราะการเรนเดอร์เป็นภาพอาจทิ้งข้อได้เปรียบของเวกเตอร์และแบนราบเนื้อหาแบบอินเทอร์แอกทีฟ

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

ตัวเลือก C: Docling เมื่อโครงสร้างมีความสำคัญ

Docling ออกแบบมาสำหรับการแปลงเอกสารโดยมีตัวเลือกเลย์เอาต์ ตาราง OCR และการประมวลผลภาษาวิชันในเครื่อง เอกสารโครงการระบุความเข้าใจ PDF ขั้นสูง โครงสร้างตาราง OCR และเอาต์พุตแบบ JSON/Markdown ที่ไม่มีการสูญเสียข้อมูล โดยมีการประมวลผลในเครื่องสำหรับเวิร์กโฟลว์ที่อ่อนไหวและออฟไลน์

การแปลงด้วย Python พื้นฐานอาจมีขนาดเล็กดังนี้:

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
doc = converter.convert("input.pdf").document

markdown = doc.export_to_markdown()
structured = doc.export_to_dict()

ดู คู่มือเริ่มต้น Docling อย่างเป็นทางการ Docling ยังรองรับไปป์ไลน์ VLM ในเครื่องและแบ็กเอนด์ OCR หลายตัว ตัวเลือกขั้นสูง ของมันอธิบายว่าการเรียกใช้บริการระยะไกลต้องเลือกเข้าร่วมอย่างชัดเจน ในขณะที่อาร์ติแฟกต์โมเดลสามารถเตรียมล่วงหน้าสำหรับการใช้งานออฟไลน์ได้

เหมาะที่สุดสำหรับ: ตารางที่ซับซ้อน หัวข้อ รายงานหลายคอลัมน์ ภาพสแกนแบบผสม หรือกรณีที่คุณต้องการการแสดงเอกสารที่ใช้ซ้ำได้แทนการเทข้อความธรรมดา

ข้อแลกเปลี่ยน: ไปป์ไลน์นี้หนักกว่าตัววิเคราะห์ PDF ธรรมดา ใช้มันเพราะโครงสร้างเพิ่มเติมช่วยเพิ่มความแม่นยำในการดึงข้อมูล ไม่ใช่เพียงเพราะมันมีองค์ประกอบมากกว่า

การดำเนินการ: เลือกวิธีการดึงข้อมูลที่เบาที่สุดที่รักษาข้อมูลที่สคีมาเป้าหมายของคุณต้องการ อย่าทำ OCR ข้อความฝังที่ชัดเจน และอย่าทิ้งเลย์เอาต์เมื่อเลย์เอาต์กำหนดความหมาย

ขั้นตอนที่ 3: จับคู่เนื้อหาที่กู้คืนเข้ากับสคีมาที่เข้มงวดด้วยโมเดลในเครื่อง

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

ตัวอย่างเช่น:

from pydantic import BaseModel
from typing import Optional

class LineItem(BaseModel):
    description: str
    quantity: Optional[float]
    unit_price: Optional[float]
    amount: Optional[float]

class Invoice(BaseModel):
    invoice_number: Optional[str]
    invoice_date: Optional[str]
    vendor_name: Optional[str]
    currency: Optional[str]
    subtotal: Optional[float]
    tax: Optional[float]
    total: Optional[float]
    items: list[LineItem]

เอกสารผลลัพธ์ที่มีโครงสร้างปัจจุบันของ Ollama รองรับการใช้ JSON Schema ผ่านฟิลด์ format และการตรวจสอบคำตอบด้วย Pydantic การเรียกใช้ในเครื่องอาจมีลักษณะดังนี้:

from ollama import chat

schema = Invoice.model_json_schema()

prompt = f"""
Extract the invoice into the supplied schema.

Rules:
- Use only information present in the source.
- Use null when a field is not found.
- Do not infer missing invoice numbers, dates, tax, or totals.
- Preserve line items individually.

SOURCE:
{text}
"""

response = chat(
    model="gpt-oss",
    messages=[{"role": "user", "content": prompt}],
    format=schema,
    options={"temperature": 0},
)

invoice = Invoice.model_validate_json(response.message.content)

วิธีนี้ปฏิบัติตามรูปแบบใน เอกสาร Structured Outputs อย่างเป็นทางการของ Ollama ซึ่งแนะนำสคีมาที่ใช้ซ้ำได้และอุณหภูมิต่ำเช่นศูนย์สำหรับการเติมเต็มที่มีโครงสร้างแบบกำหนดได้มากขึ้น

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

โมเดลข้อความหรือโมเดลวิชัน?

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

อย่างไรก็ตาม การเรนเดอร์ทุกหน้าเป็นภาพเปลี่ยนข้อแลกเปลี่ยน:

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

การดำเนินการ: เริ่มด้วยข้อความจากตัววิเคราะห์/OCR บวกกับ LLM ในเครื่องที่จำกัดด้วยสคีมา เพิ่มระดับเฉพาะประเภทหน้าที่ซับซ้อนไปยัง VLM ในเครื่องแทนที่จะจ่ายต้นทุนวิชันสำหรับทุกหน้า

ขั้นตอนที่ 4: ตรวจสอบก่อนเขียน JSON, CSV, Excel หรือฐานข้อมูล

JSON ที่ถูกต้องตามสคีมาไม่จำเป็นต้องถูกต้องตามข้อเท็จจริงโดยอัตโนมัติ โมเดลสามารถสร้างฟิลด์ที่ถูกต้องด้วยค่าที่ผิดได้ ดังนั้นขั้นตอนสุดท้ายควรใช้การตรวจสอบแบบกำหนดได้ (deterministic) เท่าที่เป็นไปได้

สำหรับใบแจ้งหนี้ การตรวจสอบที่มีประโยชน์รวมถึง:

• ฟิลด์ระบุตัวตนที่จำเป็น: หมายเลขใบแจ้งหนี้หรือชื่อผู้ขายต้องมีอยู่หากเวิร์กโฟลว์ของคุณต้องการ
• การวิเคราะห์วันที่: วิเคราะห์วันที่ด้วยนโยบายที่แน่นอนแทนที่จะเชื่อสตริงที่คลุมเครือเช่น 03/04/26
• การคำนวณ: เปรียบเทียบผลรวมของจำนวนเงินรายการย่อยกับยอดรวมย่อยของเอกสารภายในความคลาดเคลื่อนที่กำหนด
• ยอดรวม: ตรวจสอบว่ายอดรวมย่อยบวกภาษีและค่าธรรมเนียมอื่นๆ สอดคล้องกับยอดรวมหรือไม่
• สกุลเงิน: อย่าสมมติว่าเป็น USD เพียงเพราะเอกสารเป็นภาษาอังกฤษ
• แหล่งที่มา: เก็บชื่อไฟล์ต้นทาง หมายเลขหน้า เวลาที่ดึงข้อมูล และแฮชของ PDF ต้นฉบับ (ถ้ามี)
• คิวตรวจสอบ: ส่งกรณีที่ไม่พบ ขัดแย้ง หรือความเชื่อมั่นต่ำให้มนุษย์ตรวจสอบแทนที่จะเติมค่าเงียบๆ

โครงสร้างชุดงานพื้นฐานสามารถแยกการดึงข้อมูลออกจากการตรวจสอบ:

from pathlib import Path
import json

for pdf_path in Path("inbox").glob("*.pdf"):
    source_text = extract_native_text(str(pdf_path))

    # If text is unusable, run your OCR or Docling branch here.
    record = extract_with_local_model(source_text)

    errors = validate_record(record)

    if errors:
        save_for_review(pdf_path, record, errors)
    else:
        output = Path("processed") / f"{pdf_path.stem}.json"
        output.write_text(
            json.dumps(record, ensure_ascii=False, indent=2),
            encoding="utf-8"
        )

ฟังก์ชันช่วยเหลือถูกทิ้งให้เป็นเฉพาะแอปพลิเคชันโดยเจตนาเพราะกฎการตรวจสอบแตกต่างกันอย่างมากระหว่างใบแจ้งหนี้ สัญญา แบบฟอร์มภาษี รายงานห้องปฏิบัติการ และใบสั่งซื้อ ตัวตรวจสอบสากลจะสร้างความเชื่อมั่นที่ผิดพลาด

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

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

สถาปัตยกรรมในเครื่องที่ใช้งานได้จริง

สำหรับงานอัตโนมัติขนาดเล็กและขนาดกลางจำนวนมาก การแบ่งความรับผิดชอบนี้ดูแลรักษาง่ายกว่าโมเดลแบบรวมศูนย์:

PDF inbox
   |
   +-- born-digital --> PyMuPDF -------------------+
   |                                               |
   +-- scanned/mixed --> OCRmyPDF/Tesseract -------+--> normalized text/layout
   |                                               |
   +-- layout-heavy --> Docling -------------------+
                                                   |
                                                   v
                                         local LLM / VLM
                                                   |
                                            JSON Schema
                                                   |
                                                   v
                                   deterministic validation
                                                   |
                            +----------------------+----------------+
                            |                      |                |
                           JSON                   CSV             database

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

Ollama เทียบกับ llama.cpp เทียบกับ Docling VLM: ควรเลือก รันไทม์ในเครื่องตัวไหน?

ที่เก็บ llama.cpp อย่างเป็นทางการ ระบุ llama-server ในเครื่องและการสร้างที่จำกัดด้วยไวยากรณ์; รหัสเซิร์ฟเวอร์ปัจจุบันยังยอมรับข้อจำกัด JSON schema ด้วย เอกสาร Vision Models ของ Docling ระบุตัวเลือก VLM ในเครื่องสำหรับการแปลงเอกสาร

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

วิธีรักษาไปป์ไลน์ให้เป็นในเครื่องอย่างแท้จริง

“ไม่ใช้ Cloud API” ควรเป็นคุณสมบัติการปรับใช้ที่คุณสามารถตรวจสอบได้ ไม่ใช่แค่ป้ายการตลาด

Ollama

FAQ อย่างเป็นทางการของ Ollama ระบุว่าพรอมต์และคำตอบในเครื่องไม่ถูกส่งกลับไปยัง Ollama นอกจากนี้ยังระบุการตั้งค่าปิดใช้งานคลาวด์:

OLLAMA_NO_CLOUD=1

หรือการตั้งค่าเซิร์ฟเวอร์ disable_ollama_cloud ที่เทียบเท่า API ในเครื่องของ Ollama ทำงานที่ http://localhost:11434 และไม่ต้องการการยืนยันตัวตนสำหรับการเข้าถึงในเครื่อง ตาม เอกสารการยืนยันตัวตน ของมัน

จำไว้ว่าบริการที่ผูกกับ localhost ต่างจากบริการที่เปิดเผยต่อ LAN ของคุณ หากคุณเปลี่ยนที่อยู่การผูกหรือวางไว้หลังเซิร์ฟเวอร์อื่น คุณต้องรับผิดชอบการควบคุมการเข้าถึง

Docling

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

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

สิ่งที่ AI ในเครื่องไม่ได้แก้ไข

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

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

วิธีทดสอบก่อนอัตโนมัติทั้งโฟลเดอร์

สร้างชุดประเมินผลขนาดเล็กที่มีป้ายกำกับซึ่งมีกรณีที่คุณได้รับจริง:

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

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

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

บทสรุป

ระบบดึงข้อมูล PDF ในเครื่องที่ดีแยก การอ่านเอกสาร ออกจาก การดึงข้อมูลเชิงความหมาย ใช้ PyMuPDF เมื่อ PDF มีข้อความที่ดีอยู่แล้ว; OCRmyPDF/Tesseract เมื่อหน้าเป็นภาพสแกน; Docling เมื่อโครงสร้างและตารางมีความสำคัญ; และโมเดล Ollama หรือ llama.cpp ในเครื่องเมื่อคุณต้องการการจับคู่ที่ยืดหยุ่นเข้ากับสคีมาธุรกิจ ใช้วิชันในเครื่องเฉพาะเมื่อเลย์เอาต์ทางสายตาเพิ่มข้อมูลที่ไปป์ไลน์ข้อความไม่สามารถรักษาได้อย่างเชื่อถือได้

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