تصور کنید در یک سناریو در جریان کاری حسابهای پرداخت، یک ساختار JSON Schema سختگیرانه بسیار حیاتیتر از یک پرامپت هوشمندانه باشد. در یک راهنمای فنی که در ۲۰ اوت ۲۰۲۶ منتشر شد، یک توسعهدهنده ارشد استدلال میکند که ایجاد یک قرارداد سختگیرانه بین مرحله بازیابی (Retrieval) و تولید (Generation)، تنها راه برای متوقف کردن مدلهای هوش مصنوعی از ابداع دادههای جعلی در فاکتورها است. هدف در اینجا تولید یک پاراگراف که صرفاً «به نظر درست میرسد» نیست، بلکه خروجی دقیقی است که شامل یک پاسخ، یک مقدار اطمینان، فیلدهای استخراجشده دقیق، ارجاعات و پرسشهای تکمیلی باشد؛ بهگونهای که یک صفحه نمایش حسابهای پرداخت بتواند آنها را بدون نیاز به یک مرحله پردازش (Parsing) مجدد، رندر کند.
بسیاری از دموهای «پرسش از اسناد» (Ask-your-docs) روی روان بودن و پذیرفتنی بودن پاسخها بهینهسازی شدهاند. اما استخراج داده از فاکتورها با آزمون بسیار سختتری روبروست: یک بازبین انسانی باید بتواند مستقیماً از فیلد «مبلغ کل» (total_due) به مکان دقیق منبع آن در فایل PDF بپرد. اگر هوش مصنوعی نتواند شواهد را بیابد، باید از پر کردن آن فیلد خودداری کند، نه اینکه بر اساس اصطلاحات رایج تأمینکنندگان حدس بزند. برای مثال، نام یک تأمینکننده ممکن است در سربرگ، بلوک حواله، ارجاع سفارش خرید و فوتر ایمیل ظاهر شود. سیستم بازیابی میتواند هر چهار مورد را پیدا کند، اما ممکن است تنها یکی از آنها نام قانونی تأمینکنندهای باشد که جریان کاری به آن نیاز دارد.
این چالش در حالی رخ میدهد که شرکتها از نمونههای اولیه سادهی تولید بازیابیافزا (RAG) — که شبیه دانشآموزی است که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — به سمت اتوماسیون مالی در مقیاس تولید (Production-grade) حرکت میکنند. مشکل اصلی در اینجا «مرز شکست» (Failure Boundary) است؛ یعنی بدانیم آیا یک اشتباه به این دلیل رخ داده که صفحه درست سند هرگز به مدل نرسیده است (شکست بازیابی) یا به این دلیل که مدل صفحه را نادیده گرفته است (شکست تولید). ترکیب این امتیازها، مرز شکست را پنهان میکند. اگر صفحه درست هرگز به مدل نرسد، تنظیم پرامپت (Prompt Tuning) صرفاً یک نمایش تئاترگونه است؛ اما اگر صفحه موجود باشد و مدل به تکهای غایب ارجاع دهد، مشکل از بازیابی نیست.
معماری استخراج قابل راستیآزمایی
برای حل این مشکل، سیستم پیشنهادی از یک خط لوله چندمرحلهای استفاده میکند که قابلیت بازرسی (Inspectability) را بر روانی متن (Fluency) اولویت میدهد. فرآیند با بازیابی برداری (Embedding Retrieval) برای یافتن مرتبطترین تکههای فاکتور آغاز میشود. این تکهها به یک درخواست تکمیل چت (Chat Completion) ارسال میشوند که الزام شدیدی به پاسخ در قالب JSON Schema دارد. هدف این است که اطمینان حاصل شود شواهد نامعتبر نمیتوانند بهطور بیصدا به وضعیت رابط کاربری (UI State) تبدیل شوند. این رویکرد در راستای جلوگیری از توهمات عملیاتی از طریق اعتبارسنجی سختگیرانه در LLMهاست که هزینههای نظارت و خطاهای خروجی را کاهش میدهد.
مکانیزمهای فنی کلیدی عبارتند از:
- ارجاع غیرمستقیم متادیتا (Metadata Indirection): پرامپت به جای لینکهای کامل یا مسیرهای سند، شناسههای فشرده (مانند 'c1') را به مدل میدهد. این کار مانع از آن میشود که مدل لینکهای متقاعدکننده اما جعلی بسازد و جزئیات ذخیرهسازی را خارج از قرارداد تولید نگه میدارد. برای مثال در یک شرکت رسانهای، هر تکه ایندکسشده دارای یک
document_id،pageوurl_anchorاست. - محدودیتهای اسکیما (Schema Constraints): JSON Schema در حالت 'strict' تنظیم میشود؛ به این معنی که هر ویژگی ناشناخته باعث شکست اعتبارسنجی میشود و فیلدهای nullable صراحتاً نشاندهنده حقایق پشتیبانینشده هستند. امکان «خودداری از پاسخ» باید وجود داشته باشد؛ اگر شرایط پرداخت موجود نباشد، نتیجه باید یک فیلد null به همراه یک پرسش تکمیلی باشد. خروجی کوتاه پذیرفتنی است، اما خروجی بدون پشتیبانی (Unsupported) پذیرفته نیست.
- اعتبارسنجی پس از تجزیه (Post-Parse Validation): پس از اینکه مدل JSON را برگرداند، کد برنامه شناسههای فشرده را دوباره به متادیتای محلی مورد اعتماد (شناسه سند، شماره صفحه و لنگر URL) تبدیل میکند. این یک مرحله جستوجوی ساده در نقشه (Map Lookup)، کل دستهی ارجاعات جعلی را حذف میکند.
- تفکیک ارجاعات (Citation Resolution): هر ارجاع باید دقیقاً به یک شناسه سند، صفحه یا لنگر URL بازگردد که سیستم بازیابی واقعاً برگردانده است. شیء ارجاع باید متادیتای بازیابی را داشته باشد، نه متنی که در حین تکمیل توسط مدل ابداع شده است.
جزئیات پیادهسازی و منطق
برای توسعهدهندگانی که این سیستم را در Node.js یا TypeScript پیاده میکنند، منطق نیازمند یک حلقه بسته بین مدل بردار (Embedding Model) و مدل چت است. این فرآیند شامل تبدیل پرسش کاربر و تکههای فاکتور به بردار و سپس محاسبه شباهت کسینوسی (Cosine Similarity) برای انتخاب برترین کاندیدها (Top-k) است.
- گام بازیابی: بردارها، تکهها را بر اساس شباهت معنایی رتبهبندی میکنند. سیستم مرتبطترین تکهها (مثلاً دو مورد اول) را بازیابی کرده و مجموعهای از
allowedIdsمیسازد. این مجموعه به عنوان «منبع حقیقت» برای مرحله تولید بعدی عمل میکند. - گام تولید: تکمیلهای چت، شواهد انتخابشده را به پاسخ ساختاریافته نهایی تبدیل میکنند. پرامپت سیستم باید صراحتاً به مدل دستور دهد که فیلدها را فقط از شواهد ارائه شده استخراج کند و برای فیلدهای پشتیبانینشده از null استفاده کند.
- گام اعتبارسنجی: برنامه باید هر ارجاعی را که در گام بازیابی ارائه نشده بود، رد کند. اگر مدل یک
chunk_idبرگرداند که در مجموعهallowedIdsنیست، پاسخ به عنوان یک شکست در مبنیسازی (Grounding Failure) در نظر گرفته شده و رد میشود.
بررسی عمیق: پیادهسازی در TypeScript
در یک پیادهسازی عملی، سیستم یک نوع Chunk تعریف میکند که شامل id ، text ، document_id ، page و url_anchor است. نوع Answer نیز بهطور سختگیرانه تایپ شده است تا شامل پاسخ نهایی، یک عدد برای میزان اطمینان، یک شیء fields (شامل supplier_name ، invoice_number ، total_due و due_date)، آرایهای از ارجاعات و لیستی از پرسشهای تکمیلی باشد.
برای مدیریت ناپایداری فراخوانهای شبکه، کلاینت یک Wrapper به نام withRateLimitRetry را پیاده میکند. این تابع از عقبنشینی نمایی محدود (Bounded Exponential Backoff) استفاده کرده و عملیات را تا چهار بار تلاش میکند. این تابع بهطور خاص خطای OpenAI.APIError با وضعیت ۴۲۹ را بررسی میکند. اگر پاسخ شامل هدر retry-after باشد، سیستم به آن مدت زمان خاص پایبند میماند؛ در غیر این صورت، از فرمول 250 * 2 ** attempt میلیثانیه استفاده میکند.
منطق اصلی توالی خاصی را دنبال میکند: ابتدا پرسش و تمام تکههای موجود را تبدیل به بردار میکند، شباهت کسینوسی بین بردار پرسوجو و بردارهای تکهها را محاسبه کرده و دو نتیجه برتر را جدا میکند. سپس پرامپت، شواهد را در قالبی فشرده به صورت chunk_id | text به مدل میدهد. مقدار response_format روی json_schema با strict: true تنظیم میشود تا اطمینان حاصل شود که مدل نمیتواند ویژگیهای اضافی به خروجی اضافه کند.
موازنه کیفیت و تأخیر (Benchmarking)
طبق گزارش dev.to، توسعهدهندگان باید از افزودن مرحله بازرتبهبندی (Reranking) خودداری کنند مگر اینکه یک مجموعه ارزیابی ثابت ثابت کند که این کار ضروری است. بازرتبهبندی یک گام شبکه (Network Hop) دیگر اضافه میکند و تأخیر را افزایش میدهد، که اگر بازیابی برداری اولیه شواهد درست را گرفته باشد، توجیهپذیر نیست. این یک انتخاب بین بودجه کیفیت در مقابل تأخیر است. با بازیابی برداری به علاوه یک بار تکمیل شروع کنید و بازرتبهبندی را تنها زمانی اضافه کنید که یک «خطای عدم بازیابی» (Miss) اندازهگیری شده، فراخوان اضافی را توجیه کند.
برای اندازهگیری موفقیت، نویسنده پیشنهاد میکند از یک مجموعه کوچک برچسبگذاری شده از فاکتورهای «سخت» استفاده شود. این مجموعه باید شامل موارد زیر باشد:
- مبالغ کل چندصفحهای که در تکههای مختلف پخش شدهاند.
- شمارههای سفارش خرید تکراری که میتواند مدل را گیج کند.
- اعتبارات (Credit notes) و فاکتورهایی که تاریخ سررسید آنها موجود نیست.
عملکرد باید از طریق تأخیر p50 و p95 برای بازیابی و تولید بهطور جداگانه ردیابی شود. این تفکیک به اپراتورها اجازه میدهد دقیقاً ببینند گلوگاه کجاست؛ آیا در جستوجوی برداری است یا در زمان تولید LLM. هیچ حد قطع جهانی در اینجا وجود ندارد زیرا قالبهای فاکتور و هزینههای بازبینی متفاوت است.
ابزارها و انتخاب ارائهدهنده
پیادهسازی میتواند با ترکیبهای مختلفی از ارائهدهندگان بر اساس نیازهای عملیاتی ساخته شود. توصیه میشود انتخاب بر اساس مجموعه فاکتورهای برچسبگذاری شده باشد، نه بر اساس طولانیترین لیست ویژگیها.
گزینههای بازیابی و بازرتبهبندی:
- Pinecone: یک کاندیدای بازیابی مدیریتشده برای اندازهگیری نرخ بازیابی شواهد (Recall) و تأخیر پرسوجو. این ابزار لایه بازیابی را مدیریت میکند و تولید را به عنوان یک ادغام مجزا باقی میگذارد.
- Elasticsearch: گزینهای جذاب زمانی که اسناد و عملیات جستوجو از قبل در آنجا هستند و بازیابی ترکیبی (Hybrid) را روی اصطلاحات و معنای فاکتورها ارائه میدهد.
- Cohere: یک کاندیدای تخصصی برای بازرتبهبندی. زمانی باید تست شود که بازرتبهبندی به عنوان گلوگاه اندازهگیری شده برای بهبود بازیابی ارجاعات پس از بازآرایی شناسایی شود، هرچند یک رابطه پرداخت و اعتبارنامه جدید اضافه میکند.
گزینههای تولید و تجمیع:
- OpenAI: یک خط پایه مستقیم برای تکمیل چت جهت بررسی رعایت اسکیما و دقت فیلدهای مبنیسازی شده. این یک ساختار تمیز است وقتی حجم کار با یک ارائهدهنده باقی میماند.
- Anthropic Claude: جایگزینی برای تست دقت فیلدها تحت همان بودجه شواهد. این کار در صورتی که بقیه پشته OpenAI-compatible باشد، یک قرارداد کلاینت دوم ایجاد میکند.
- Google Gemini: جایگزینی برای اندازهگیری رعایت اسکیما و تأخیر روی مجموعه فاکتورهای ثابت. انتخاب مدل در اینجا به ارائهدهنده گوگل وابسته است.
- OpenRouter: یک جایگزین مسیریابی چندمدلی که به بهبود کیفیت بین مدلها با استفاده از یک محیط تست پایدار کمک میکند. این ابزار در انتخاب مدل کمک میکند اما مالک ایندکس بازیابی نیست.
- Infrai: یک گزینه تجمیعی سازگار با OpenAI. به یک تیم کوچک اجازه میدهد با یک کلید و یک صورتحساب، سطح گستردهای از بکاند (شامل بازرتبهبندی و بردارها) را از طریق یک API REST توصیفشونده استفاده کند. با این حال، نقطه انتهایی اختصاصی برای تعدیل (Moderation) ارائه نمیدهد (که باید از طریق گاردریلهای JSON Schema مدیریت شود) و ASR برای ورودیهای صوتی ندارد، زیرا قابلیت نشستهای صوتی بلادرنگ آن در حال حاضر محدود به مناطق غربی است.
مدیریت شکستهای عملیاتی
تفاوت حیاتی بین شکستهای عملیاتی و شکستهای شواهدی وجود دارد. خطای ۴۲۹ محدودیت نرخ (Rate-limit)، یک نقص فنی است که با عقبنشینی نمایی محدود حل میشود. کلاینت باید در صورت وجود هدرهای 'Retry-After'، آنها را رعایت کند. در پیادهسازی TypeScript، باید از یک بودجه تلاش مجدد (مثلاً ۴ بار) قبل از پرتاب خطای اتمام محدودیت نرخ استفاده شود.
اما پاسخی که به یک شناسه تکه (مانند 'c9') ارجاع میدهد که هرگز بازیابی نشده است، یک شکست در مبنیسازی (Grounding Failure) است. در محیط تولید، مورد دوم باید رد و بازرسی شود. نویسنده توصیه میکند برای هرگونه عملیات نوشتن (Write) در خط لوله از کلیدهای Idempotency استفاده شود تا اطمینان حاصل شود که تلاشهای مجدد باعث تکرار رکوردهای مالی نمیشوند، هرچند فرآیند استخراج که ماهیت خواندنی دارد، عملیات ایجاد (Create) انجام نمیدهد.
نقش امتیازات اطمینان
مقادیر اطمینان ارائه شده توسط مدلها باید برای مسیریابی (Routing) استفاده شوند، نه به عنوان ادعایی از حقیقت. امتیاز ۰.۹۱ صرفاً یک سیگنال از سوی مدل است تا نتیجه را به یک بازبین انسانی ارسال کند. این امتیاز نباید به یک ادعای دقت کالیبره شده تبدیل شود، مگر اینکه یک ارزیابی برچسبگذاری شده، کالیبراسیون را برای دقیقاً همان فاکتورها، مدل، پرامپت و تنظیمات بازیابی مورد استفاده ثابت کند.
در نهایت، هدف این است که «اشتباه بودن» قابل بازرسی باشد. با اجبار مدل به رعایت یک قرارداد سختگیرانه، برنامه میتواند دقیقاً مشخص کند کدام فیلد پشتیبانی نمیشود و به جای ارائه یک حدس توهمآمیز به عنوان حقیقت، یک پرسش تکمیلی خاص بپرسد.
این تغییر در عمل، هوش مصنوعی را از یک «مسابقه نویسندگی» به یک ابزار جریان کاری قابل اعتماد تبدیل میکند. تمرکز از اینکه هوش مصنوعی «چگونه به نظر میرسد» به این تغییر میکند که «آیا دادههای استخراجشده توسط یک حسابدار انسانی در چند ثانیه قابل حسابرسی هستند یا خیر». هر فراخوان اضافی مدل، هزینهای در تأخیر دارد، حتی زمانی که پشت یک اسپینر در UI پنهان شده باشد؛ بنابراین، سیستم باید از افزودن فراخوان دوم مدل صرفاً برای زیباتر کردن متن خودداری کند.
برای پیادهسازی این مورد، با ساخت یک Regression Fixture برای هر قالب تأمینکننده شروع کنید. یک Fixture مفید، متن اصلی تکه، فیلدهای مورد انتظار، شناسههای ارجاع پذیرفته شده و دلیل اینکه چرا یک فیلد غایب باید null باقی بماند را ذخیره میکند. این Fixture را بعد از هر تغییر مدل، ویرایش پرامپت، بهروزرسانی OCR یا مهاجرت تکهبندی (Chunking) اجرا کنید. چهار مرحله را بهطور جداگانه گزارش کنید: بازیابی اولیه، بازرتبهبندی اختیاری، تولید ساختاریافته و اعتبارسنجی محلی ارجاعات. این ردپای طولانیتر به اپراتور میگوید که آیا باید اسناد را دوباره ایندکس کند، top-k را تنظیم کند، اسکیما را تغییر دهد یا پاسخ ارائهدهنده را بازرسی کند.
گام بعدی شما
- برای هر قالب فاکتور تأمینکنندگان خود، یک مجموعه داده مرجع (Regression Fixture) بسازید که شامل متن تکهها، فیلدهای مورد انتظار و شناسههای ارجاع پذیرفته شده باشد.
- مراحل چهارگانه (بازیابی، بازرتبهبندی، تولید ساختاریافته و اعتبارسنجی محلی) را بهطور جداگانه ردیابی کنید تا گلوگاه سیستم را بیابید.
- از JSON Schema با حالت strict استفاده کنید تا هرگونه خروجی خارج از قرارداد فوراً شناسایی و رد شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو