رویکرد مبتنی بر اسکیما در برابر مدل‌های ابری پیش‌ساخته در استخراج داده

اگر امروز برای مدیریت حساب‌های پرداختنی (Accounts Payable) با کوهی از فایل‌های PDF و تصاویر دست‌وپنجه نرم می‌کنید، خروجی JSON ساختاریافته تنها چیزی است که واقعاً برای شما اهمیت دارد. Anyformat یک API استخراج داده توسعه داده است که اسناد را به داده‌های ماشین‌خوان تبدیل کرده و مسیری مستقیم برای ادغام با سیستم‌های ERP یا سیستم‌های حسابداری ایجاد می‌کند.

بسیاری از کسب‌وکارها در حال حاضر با شکافی عمیق میان متن خام حاصل از نویسه‌خوانی نوری (OCR) — که شبیه به کسی است که کلمات را می‌بیند اما معنای آن‌ها را نمی‌فهمد — و داده‌های کاربردی دست‌وپنجه نرم می‌کنند. در حالی که OCR سنتی صرفاً کاراکترها را می‌خواند، یک API استخراج باید بتواند نقش خاص آن متن را شناسایی کند؛ مثلاً تفاوت بین «جمع پیش از مالیات» (Subtotal) و «جمع کل» (Grand Total) یا «نام فروشنده» و «آدرس ارسال» را بفهمد. این چرخش از «خواندن» به «درک»، همان چیزی است که جریان‌های کاری مالی را خودکار می‌کند.

زمینه و ضرورت استخراج داده‌های فاکتور

برای تیم‌های مالی و حساب‌های پرداختنی، هدف دریافت یک تخلیه متنی (Text Dump) نیست، بلکه داشتن رکوردی است که آماده ثبت در سیستم حسابداری باشد. بر اساس مستندات این سرویس، یک API حرفه‌ای باید فیلدهای سربرگی (Header Fields) خاصی را استخراج کند: شماره فاکتور، نام فروشنده، تاریخ صدور، تاریخ سررسید، ارز، مبلغ پیش از مالیات، مبلغ مالیات و جمع کل.

علاوه بر سربرگ، سیستم باید بتواند اقلام تفکیکی (Line Items) را مدیریت کند و برای هر ردیف، شرح کالا، تعداد، قیمت واحد و مبلغ را ثبت نماید. تفاوت کلیدی میان یک API سطح بالا و یک اسکریپت ساده OCR در وجود «امتیاز اطمینان» (Confidence Scores) و «شواهد» (Evidence) است. بدون این دو، کاربر نمی‌داند که یک مقدار، یک حقیقت است یا صرفاً حدس مدل.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و دقت مدل‌های استخراج داده اشاره کردیم، حذف توهمات در داده‌های مالی یک ضرورت است، نه یک ویژگی جانبی. در همین راستا، تفکیک فرآیند استخراج از اعتبارسنجی راهکاری کلیدی برای حذف توهمات عددی در فاکتورهاست که پیش‌تر بررسی کردیم.

الزامات حیاتی برای خودکارسازی پرداخت‌ها

برای اینکه خروجی برای عملیات مالی کاربردی باشد، باید معیارهای سخت‌گیرانه‌ای را رعایت کند:

• عدم تولید مقادیر ساختگی: وقتی فیلدی در سند وجود ندارد، API باید مقدار تهی (null) برگرداند، نه اینکه حدس بزند. این کار از خطاهای مالی ناشی از توهم (Hallucination) — شبیه به دوستی که خاطره‌ای را اشتباه تعریف می‌کند — جلوگیری می‌کند. این رویکرد با الگوی n8n برای حذف قدرت تصمیم‌گیری از هوش مصنوعی همسو است تا از کلاهبرداری‌های مالی احتمالی جلوگیری شود.
• امتیاز اطمینان (Confidence Scores): هر مقدار باید امتیازی داشته باشد تا سیستم تصمیم بگیرد چه چیزی به‌طور خودکار ثبت شود و چه چیزی نیاز به بررسی انسانی دارد.
• شواهد تأیید (Verification Evidence): API باید متن دقیق و شماره صفحه را برای هر مقدار ارائه دهد تا بازبین بتواند داده را در چند ثانیه تأیید کند، به‌جای اینکه کل فاکتور را دوباره بخواند.

گردش کار سه مرحله‌ای استخراج

به نقل از راهنمای فنی anyformat.ai که در اکتبر ۲۰۲۶ ارزیابی شد، فرآیند استخراج از یک توالی سه مرحله‌ای سخت‌گیرانه پیروی می‌کند:

۱. ایجاد گردش کار (Workflow Creation): کاربر یک اسکیما (Schema) را با استفاده از یک گره تجزیه (Parse Node) و یک گره استخراج (Extract Node) تعریف می‌کند. این اسکیما فیلدهای دقیق مورد نیاز را مشخص می‌کند. برای مثال، یک اسکیمای معمولی فاکتور شامل موارد زیر است:
* invoice_number: رشته (شناسه فاکتور چاپ شده روی سند)
* vendor_name: رشته (شرکتی که فاکتور را صادر کرده است)
* issue_date: تاریخ (تاریخ صدور فاکتور)
* due_date: تاریخ (تاریخ سررسید پرداخت)
* subtotal: عدد اعشاری (جمع کل پیش از مالیات)
* tax_amount: عدد اعشاری (جمع کل مالیات)
* total_amount: عدد اعشاری (جمع کل نهایی برای پرداخت)
* currency: شمارشی/Enum (گزینه‌ها: USD, EUR, GBP)
* line_items: شیء (فیلدهای تو در تو برای شرح، تعداد، قیمت واحد و مبلغ)

۲. بارگذاری سند (Document Upload): فاکتور در برابر یک شناسه گردش کار (Workflow ID) خاص از طریق یک درخواست POST به نقطه اتصال /upload/run/ ارسال می‌شود. این درخواست یک run_id و یک document_packet_id برمی‌گرداند و وضعیت را در حالت queued (در صف) قرار می‌دهد.

۳. بازیابی نتیجه (Result Retrieval): سیستم شناسه اجرا (Run ID) را بازبینی (Poll) می‌کند. نقطه اتصال همیشه با وضعیت ۲۰۰ پاسخ می‌دهد، اما فیلد status در بدنه JSON نشان می‌دهد که آیا اجرا در حالت queued (در صف)، in_progress (در حال پردازش)، processed (پردازش‌شده)، error (خطا) یا cancelled (لغو شده) است. پس از رسیدن به وضعیت processed است، JSON ساختاریافته بازگردانده می‌شود.

پیاده‌سازی فنی و محدودیت‌ها

توسعه‌دهندگان می‌توانند این جریان را با Python یا curl پیاده کنند. در پایتون، یک پیاده‌سازی مستحکم نیازمند بازبینی (Polling) با تأخیر تصاعدی (Backoff) است. با استفاده از کتابخانه requests، یک تابع می‌تواند فایلی را آپلود کرده و سپس وارد یک حلقه شود؛ به‌طوری که با تأخیر ۴ ثانیه‌ای شروع شده و تا حداکثر ۳۰ ثانیه دو برابر شود و تا ۶۰ تلاش برای بررسی وضعیت انجام دهد، پیش از آنکه خطای TimeoutError صادر کند.

برای حفظ پایداری سیستم، ارسال درخواست‌ها به ۶۰ مورد در دقیقه محدود شده است، در حالی که سایر نقاط اتصال سقف ۶۰۰ درخواست دارند. همچنین برای جلوگیری از تکرار عملیات در هنگام تلاش مجدد شبکه (Network Retries)، توسعه‌دهندگان باید از هدر Idempotency-Key در تمام درخواست‌های POST استفاده کنند.

فراتر از متن: قدرت شواهد و متادیتا

Anyformat با ارائه متادیتا برای هر مقدار، خود را از اسکریپت‌های ساده OCR متمایز می‌کند. هر فیلد در مسیر results.extractions[0].fields مقدار، امتیاز اطمینان، وضعیت تأیید و «شواهد» (Evidence) را برمی‌گرداند.

به‌طور حیاتی، API «شواهد» را ارائه می‌دهد؛ یعنی قطعه متن دقیق و شماره صفحه‌ای که مقدار در آن یافت شده است. برای مثال، اگر total_amount برابر با «۲۱۴۱.۷» باشد، شواهد ممکن است به این صورت باشد: {"text": "Total due (EUR) 2,141.70", "page_number": 1}. این قابلیت به حسابرس اجازه می‌دهد بدون خواندن کل سند، صحت عدد را در چند ثانیه بسنجد.

مثال از خروجی ساختاریافته

برای یک فاکتور فرضی، خروجی JSON برای یک فیلد سربرگ و یک آیتم تفکیکی به این شکل خواهد بود:

• شماره فاکتور: {"value": "INV-2026-0417", "value_override": null, "verification_status": "not_verified", "confidence": 91.0, "evidence": [{"text": "Invoice number: INV-2026-0417\nIssue date: 2026-09-15\nDue date: 2026-10-15", "page_number": 1}]}
• شرح اقلام: {"value": "Cloud hosting, September", "value_override": null, "verification_status": "not_verified", "confidence": 98.0, "evidence": [{"text": "Cloud hosting, September | 1 | 1,200.00 | 1,200.00", "page_number": 1}]}

این سیستم به‌گونه‌ای طراحی شده که در صورت نبود فیلد، مقدار null برگرداند. مدل مقداری را اختراع نمی‌کند وقتی سند حاوی آن نیست، و این امر مانع از «توهماتی» می‌شود که در LLMهای عمومی رایج است. این موضوع به شرکت‌ها اجازه می‌دهد یک آستانه اطمینان (Confidence Threshold) تعیین کنند؛ مقادیر بالای آستانه به‌طور خودکار ثبت شده و مقادیر پایین‌تر به بازبین انسانی ارجاع داده می‌شوند.

مدیریت جداول پیچیده و حالت عامل‌محور

استخراج جداول از نظر تاریخی سخت‌ترین بخش پردازش فاکتورها بوده است. Anyformat این مشکل را با تعریف line_items به عنوان یک شیء با ستون‌های تو در تو حل کرده است. هر ردیف در فاکتور به یک ورودی در یک لیست تبدیل می‌شود. هر سلول — شامل شرح، تعداد، قیمت واحد و مبلغ — امتیاز اطمینان و شواهد مجزای خود را حفظ می‌کند.

برای فاکتورهای متراکم یا پیچیده، پلتفرم حالت عامل‌محور (Agentic mode) را ارائه می‌دهد. این حالت به‌طور خاص برای جداولی طراحی شده است که در چندین صفحه پخش شده‌اند. با این حال، کاربران باید توجه داشته باشند که حالت Agentic در حال حاضر از اسناد چندفایلی (Multi-file documents) پشتیبانی نمی‌کند.

مقایسه بازار و تحلیل هزینه‌ها

در مقایسه با غول‌های ابری، توازن میان انعطاف‌پذیری و هزینه تعیین‌کننده است. طبق بررسی وضعیت بازار در اکتبر ۲۰۲۶:

• OCR + Regex/Templates: بسیار شکننده، نیاز به قالب‌های جدید برای هر چیدمان فروشنده و بدون امتیاز اطمینان. هزینه اصلی آن زمان مهندسی است.
• AWS Textract (AnalyzeExpense): مدل پیش‌ساخته. امتیاز اطمینان را به ازای هر فیلد ارائه می‌دهد. هزینه آن ۱۰ دلار به ازای هر ۱۰۰۰ صفحه است (۰.۰۱ دلار به ازای هر صفحه تا ۱ میلیون صفحه در منطقه US West Oregon).
• Google Document AI: پارسر پیش‌ساخته فاکتور. هزینه آن ۰.۱۰ دلار به ازای هر سند (تا ۱۰ صفحه) است که باعث می‌شود فاکتورهای تک‌صفحه‌ای گران‌تر از سایر گزینه‌ها باشند.
• Azure Document Intelligence: مدل پیش‌ساخته. برای سفارشی‌سازی به داده‌های آموزشی برچسب‌گذاری‌شده نیاز دارد. هزینه آن ۱۰ دلار به ازای هر ۱۰۰۰ صفحه است.
• Anyformat: مبتنی بر اسکیما. از هر نوع اسکیمای سفارشی و فیلدهای شیء تو در تو پشتیبانی می‌کند. امتیاز اطمینان را به همراه شواهد برای هر مقدار ارائه می‌دهد. قیمت‌گذاری آن مبتنی بر اعتبار (Credit) است.

جزئیات قیمت‌گذاری

قیمت‌گذاری Anyformat بر اساس اعتبار به ازای هر صفحه و هر اپراتور است. در نرخ‌های استاندارد، هر صفحه فاکتور ۶۰ اعتبار هزینه دارد (۲۵ برای Standard Parse و ۳۵ برای Standard Extract).

• طرح Business: هر اعتبار ۰.۰۰۱ یورو است، که منجر به ۰.۰۶ یورو به ازای هر صفحه (۶۰ یورو به ازای هر ۱۰۰۰ صفحه) می‌شود.
• طرح Free/Pay-as-you-go: هر اعتبار ۰.۰۰۱۵ یورو است، که منجر به ۰.۰۹ یورو به ازای هر صفحه می‌شود.
• حالت عامل‌محور (Agentic Mode): ۱۰۰ اعتبار برای Parse و ۱۵۰ اعتبار برای Extract به ازای هر صفحه هزینه دارد.
• سطح رایگان (Free Tier): ۵۰,۰۰۰ اعتبار یک‌باره ارائه می‌دهد (بدون نیاز به کارت اعتباری) که تقریباً برای ۸۰۰ فاکتور تک‌صفحه‌ای با نرخ‌های استاندارد کافی است.

محدودیت‌های پیاده‌سازی

برای جلوگیری از تأخیر در عیب‌یابی، توسعه‌دهندگان باید به محدودیت‌های فنی خاص توجه کنند:

• کیفیت سند: دقت مدل در برابر اسناد کج (Skew)، نویزی یا دست‌نویس کاهش می‌یابد. این اسناد باید همیشه از طریق یک مرحله بررسی انسانی هدایت شوند.
• اسناد چندصفحه‌ای/چندفایلی: در حالی که حالت Agentic جداول طولانی را در چندین صفحه مدیریت می‌کند، اما از اسناد چندفایلی پشتیبانی نمی‌کند. اگر یک PDF شامل چندین فاکتور مختلف است، کاربران باید یک مرحله جداسازی (Split) اضافه کنند تا هر فاکتور به‌طور جداگانه از طریق لیست extractions استخراج شود.
• انواع داده: تمام مقادیر در پاسخ JSON به صورت رشته (String) ارسال می‌شوند، حتی برای اعداد و تاریخ‌ها. توسعه‌دهندگان باید آن‌ها را با استفاده از نوع داده تعریف‌شده در اسکیما تبدیل (Cast) کنند.
• حریم خصوصی: حذف کامل داده‌ها (Zero data retention) فقط یک گزینه در طرح Enterprise است. به کاربران طرح‌های Free و Business توصیه می‌شود برای رعایت دستورالعمل‌های GDPR، از فاکتورهای فرضی برای تست استفاده کنند.

این چرخش به سمت استخراج کنترل‌شده با اسکیما به این معناست که توسعه‌دهندگان دیگر مجبور نیستند بین قالب‌های شکننده Regex و مدل‌های صلب پیش‌ساخته یکی را انتخاب کنند. در اینجا، کاربر تعریف می‌کند که «حقیقت» سند چیست، نه ارائه‌دهنده هوش مصنوعی.

برای ارزیابی این ابزارها، بهترین روش تست ۵۰ فاکتور واقعی از تأمین‌کنندگان خودتان است. دقت هر فیلد و درصد اسنادی که بدون دخالت انسان از خط لوله عبور می‌کنند را اندازه‌گیری کنید.

گام بعدی شما

• ۵۰ نمونه فاکتور واقعی از تأمین‌کنندگان مختلف را برای سنجش نرخ صحت (Accuracy) تست کنید.
• برای فاکتورهای چندصفحه‌ای، حالت Agentic را فعال کرده و خروجی جداول را با داده‌های مرجع مقایسه کنید.
• در پیاده‌سازی پایتون، حتماً از Idempotency-Key برای جلوگیری از ثبت تکراری داده‌ها در سیستم‌های مالی استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.