تصور کنید برنامه‌نویسی هستید که باید سیستمی بسازد که هزاران فاکتور پیچیده را با سفارشات خرید (POs) تطبیق دهد، بدون اینکه حتی یک سنت خطا رخ دهد. در چنین سیستمی، اگر هوش مصنوعی تصمیم بگیرد اعداد را برای «منطقی‌تر شدن» تغییر دهد، شما با یک فاجعه در حسابرسی مالی رو‌به‌رو خواهید بود.
به نقل از راهنمای فنی منتشر شده در dev.to در تاریخ ۱۴ اکتبر ۲۰۲۶، موفقیت یک خط لوله تولیدی که از Claude-Sonnet-5.5 و Node.js استفاده می‌کند، به یک مرز معماری سخت بستگی دارد: مدل می‌خواند، اما کد تصمیم می‌گیرد.
این رویکرد در زمانی ارائه می‌شود که سازمان‌ها با عدم اطمینان ذاتی مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در انجام محاسبات ریاضی دست‌وپنجه نرم می‌کنند. در حالی که ما پیش‌تر بررسی کردیم که چگونه Claude Code در نوشتن وصله‌های (Patches) هسته لینوکس کمک کرد، اما به‌کارگیری هوش مصنوعی در سوابق مالی نیازمند سطح متفاوتی از سخت‌گیری است. این استراتژی یادآور الگوی پیاده‌سازی در n8n است که با حذف قدرت تصمیم‌گیری از AI، ریسک کلاهبرداری و خطاهای مالی را به حداقل می‌رساند. در یک گردش‌کار دستی معمولی، کارکنان PDFها را باز می‌کنند، شماره سفارش خرید را در سیستم ERP می‌یابند و اقلام را یکی‌یکی مقایسه می‌کنند؛ فرآیندی که کند است اما از نظر منطقی سازگار است. اکثر فاکتورها مشکلی ندارند، اما تیم باز هم تک‌تک آن‌ها را بررسی می‌کند.
زمینه: چه زمانی به اتوماسیون سفارشی نیاز داریم؟
هر کسب‌وکاری به خط لوله سفارشی Node.js نیاز ندارد. اگر شرکتی ماهانه تنها چند ده فاکتور از تعداد محدودی تأمین‌کننده دریافت می‌کند، نویسه‌خوانی نوری (OCR) داخلیِ ابزارهای حسابداری استاندارد، در ترکیب با یک بررسی دستی سریع، کاملاً کافی است.
ساخت سیستم‌های سفارشی زمانی ضروری می‌شود که:
- حجم فاکتورها یا تعداد تأمین‌کنندگان به‌قدری زیاد باشد که بررسی‌های دستی به گلوگاه اصلی تبدیل شوند.
- سفارشات خرید در یک سیستم قدیمی (Legacy) ذخیره شده باشند که ابزارهای آماده و تجاری امکان دسترسی به آن‌ها را ندارند.
- کسب‌وکار به یک «تطبیق سه‌گانه» (Three-way match) سخت‌گیرانه نیاز داشته باشد که شامل فاکتور، سفارش خرید و رسید دریافت کالا (Goods Received Note) باشد.
مکانیزم استخراج داده
این خط لوله با ارسال PDF فاکتور به Claude و اجبار مدل به «فراخوانی تابع» (Function Calling) آغاز می‌شود. مدل به‌جای پاسخ‌های متنی آزاد، باید یک شیء JSON با ساختاری سخت‌گیرانه برگرداند. این امر تضمین می‌کند که خروجی ساختاریافته و پیش‌بینی‌پذیر باشد.
برای جلوگیری از اینکه مدل خطاها را به‌صورت خودسرانه «اصلاح» کند، در پرامپت صراحتاً هرگونه محاسبه، گرد کردن یا تصحیح مقادیر ممنوع شده است. مدل موظف است فیلدها را دقیقاً همان‌طور که چاپ شده‌اند ثبت کند. اگر فیلدی مفقود یا نامشخص باشد، مدل نباید حدس بزند، بلکه باید آن را در آرایه unreadable_fields فهرست کند.
مبالغ به‌صورت رشته (String) استخراج می‌شوند. این یک انتخاب طراحی حیاتی است؛ زیرا به کد Node.js اجازه می‌دهد اعداد را تجزیه کند و اگر فرمت نامعتبر بود، به‌جای پذیرش یک عدد اشتباه، خطای شدیدی صادر کند. برای مثال، مبلغی که با فرمت اروپایی (مانند "1.250,00") نوشته شده باشد، باعث شکست تجزیه‌کننده (Parser) و صدور خطا می‌شود. این حالت ترجیح داده می‌شود زیرا یک خطای بلند و واضح، بسیار بهتر از عددی است که به‌طور خاموش اشتباه است.
موتور تطبیق مبتنی بر قانون
پس از استخراج داده، هوش مصنوعی به‌طور کامل از فرآیند حذف می‌شود. منطق تطبیق توسط جاوااسکریپت خالص مدیریت می‌شود که ارزها را به کوچک‌ترین واحد صحیح (مانند سنت یا پیزه) تبدیل می‌کند تا از خطاهای ممیز شناور (Floating-point) جلوگیری شود. مدل در این مرحله هیچ نقشی ندارد.
طبق گزارش dev.to، سیستم چندین بررسی سخت را اجرا می‌کند:
- وجود سفارش خرید: تأیید می‌کند سفارش در سیستم داخلی موجود است. فاکتوری که سفارش خرید نداشته باشد، به‌جای اینکه یک تسک ورود داده باشد، به عنوان یک پرسش سیاستی برای انسان علامت‌گذاری می‌شود.
- اعتبارسنجی تأمین‌کننده: تطبیق نام تأمین‌کننده از طریق نرمال‌سازی. در محیط تولید، این راهنما توصیه می‌کند که تطبیق بر اساس یک شناسه تأمین‌کننده (Supplier ID) از طریق یک جدول نام‌های مستعار (Alias Table) انجام شود، نه نام‌های خام؛ تا از پرداخت مبلغ درست به طرف اشتباه جلوگیری شود.
- بررسی مقدار: مقایسه مقدار فاکتور با مقدار باقی‌مانده (
remaining_qty) در سفارش خرید. این مورد به‌طور خاص مواردی را شناسایی می‌کند که فاکتور دوم برای همان محموله ارسال شده باشد. - تلورانس قیمت: بررسی اینکه آیا قیمت واحد در یک محدوده تلورانس خاص قرار دارد یا خیر. این تلورانس توسط بخش مالی تعیین شده و در یک فایل تنظیمات (Config) نگهداری می‌شود تا حسابدار بتواند آن را ببیند، و هرگز داخل پرامپت قرار نمی‌گیرد.
- تأیید محاسباتی: جمع زدن اقلام و مقایسه آن‌ها با جمع کل چاپ‌شده. این کار خطاهای محاسباتی خودِ تأمین‌کننده یا هرگونه جابجایی در استخراج را که در آن AI عددی را برای سازگاری تغییر داده باشد، شناسایی می‌کند.
اگر فاکتور شامل ردیف‌های مالیات یا هزینه حمل‌ونقل باشد، این موارد به‌عنوان فیلدهای مجزا استخراج شده و پیش از بررسی نهایی به جمع کل محاسبه‌شده اضافه می‌شوند.
مدیریت استثناها
فاکتورهای سالمی که تمام بررسی‌ها را پاس می‌کنند، به‌طور خودکار برای ثبت نهایی علامت‌گذاری می‌شوند. هر فاکتوری که در یک بررسی شکست بخورد — یا حاوی unreadable_fields باشد — به یک صف بررسی ارسال می‌شود که توسط BullMQ مدیریت می‌گردد.
رابط کاربری بازبین به‌گونه‌ای طراحی شده که PDF، فیلدهای استخراج‌شده و خط سفارش خرید را به‌صورت کنار‌هم نشان دهد. سیستم هر کد خطای احتمالی را با کلمات ساده توضیح می‌دهد. هر اصلاحی که توسط بازبین انسانی انجام شود، ثبت می‌گردد تا یک مجموعه داده استاندارد (Gold-standard) برای تکرارهای آینده در بهبود پرامپت‌های مدل ایجاد شود.
با نظارت بر کدهای استثنا به تفکیک تأمین‌کننده، تیم‌ها می‌توانند تشخیص دهند چه زمانی یک تأمین‌کننده قالب فاکتور خود را تغییر داده است. اگر کد TOTAL_DOES_NOT_ADD_UP ناگهان برای یک تأمین‌کننده خاص جهش کند، تیم می‌تواند پیش از پرداخت یک صورت‌حساب اشتباه، تغییر قالب را شناسایی کند.
تحلیل: هزینه استقلال هوش مصنوعی
این معماری میل خطرناک مدل‌های زبانی به «هم‌راستا کردن اعداد» را حل می‌کند. اگر اقلام یک فاکتور با جمع کل همخوانی نداشته باشد، مدلی که از او «جمع کل» را بخواهیم، ممکن است عددی را برگرداند که از نظر ریاضی درست است اما اصلاً روی کاغذ نیست. در یک حسابرسی مالی، دقیقاً همین شکاف است که باید شناسایی شود.
برای توسعه‌دهنده، این به معنای تغییر نقش AI از «تصمیم‌گیرنده» به «OCR با دقت بالا» است. نتیجه، سیستمی است که هم مقیاس‌پذیر است و هم قابل حسابرسی. اگر مدل تصمیم‌گیرنده باشد، اشتباهات تا زمان تطبیق سالانه یا حسابرسی رسمی شناسایی نمی‌شوند و شرکت باید پرداخت‌های اشتباه را پس بگیرد، به‌جای آنکه صرفاً داده‌ها را اصلاح کند.
در مقابل، اگر خط لوله بیش از حد حساس باشد و همه چیز را به بازبین انسانی بفرستد، کاربران در عرض چند هفته سیستم را رها می‌کنند زیرا دوباره همان شغل قدیمی خود را انجام می‌دهند، با این تفاوت که باید یادداشت‌های سیستم را هم بخوانند. هدف دقیق است: شناسایی هر عدم تطبیق واقعی و عبور فاکتورهای سالم بدون دخالت انسان.
این الگو فراتر از فاکتورها کاربرد دارد. هر گردش‌کاری که ورودی‌های نامنظم (مانند ادعاهای خسارت، فرم‌های ثبت‌نام، رسیدهای تحویل یا درخواست‌های خرید) و قوانین سخت‌گیرانه دارد، می‌تواند از این تفکیک «استخراج-سپس-اعتبارسنجی» بهره ببرد.
برای پیاده‌سازی این سیستم در یک بک‌اند موجود، توسعه‌دهندگان باید بر پیاده‌سازی مکانیزم‌های تلاش مجدد (Retries)، مهلت‌های زمانی (Timeouts) و ثبت وقایع (Logging) قدرمند در اطراف فراخوانی مدل تمرکز کنند تا تضمین شود خط لوله ورودی تاب‌آور باقی می‌ماند. برای کسانی که به دنبال بررسی حرفه‌ای جریان ورودی خود هستند، Geminate Solutions یک بررسی رایگان برنامه با زمان پاسخگویی ۲۴ ساعته ارائه می‌دهد.
گام بعدی شما
- اگر از LLM برای استخراج داده‌های عددی استفاده می‌کنید، خروجی را به‌صورت String بگیرید و محاسبات را به کد منتقل کنید.
- برای مدیریت صف‌های بررسی انسانی در Node.js، کتابخانه BullMQ را برای تضمین پایداری بررسی کنید.
- یک جدول نام‌های مستعار (Alias Table) برای تأمین‌کنندگان بسازید تا خطاهای تایپی در نام‌ها باعث توقف سیستم نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو