درون معماری جدید تریاژ؛ استفاده از گیت‌های JSON برای کنترل خروجی

اگر امروز تیکت‌های پشتیبانی خود را به هوش مصنوعی می‌سپارید، احتمالاً با پاسخ‌هایی روبرو شده‌اید که بسیار متقاعدکننده به نظر می‌رسند اما هیچ ریشه‌ای در مستندات شما ندارند. در واقع، یک پاسخ روان از سوی مدل‌های زبانی بزرگ (LLM) ممکن است مقتدرانه به نظر برسد، اما اغلب صرفاً یک حدس محتمل است تا یک پشتیبانی مبتنی بر شواهد. برای اینکه تریاژ پشتیبانی واقعاً قابل بازرسی باشد، تنها راهکار عملی استفاده از یک گیت استناد سخت‌گیرانه و یک دفتر کل محدود به هر مشتری (Tenant-scoped ledger) است.

این ضرورت در یک راهنمای فنی منتشر شده در ۱۶ اوت ۲۰۲۶ برجسته شد که مسیری آماده برای محیط عملیاتی (Production-ready) را توصیف می‌کرد. راهکار پیشنهادی این است که با نتایج بازیابی به عنوان تنها منبع حقیقت و خروجی مدل به عنوان داده‌ای غیرقابل اعتماد برخورد شود.

این رویکرد در زمانی ارائه می‌شود که سازمان‌ها برای انتقال تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — از محیط نمونه‌سازی به محیط عملیاتی دست‌وپنجه نرم می‌کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه بردارها (Embeddings) معنا را به هندسه برای جست‌وجوی معنایی تبدیل می‌کنند اشاره کردیم، چالش فعلی دیگر یافتن سند درست نیست، بلکه اطمینان از این است که هوش مصنوعی شماره صفحه یا سیاستی را اختراع نکند که اصلاً وجود ندارد. در محیط پشتیبانی، یک پاسخ زمانی از نظر عملیاتی ناقص است که یک مهندس آن‌کال (On-call) نتواند فوراً شواهد را تأیید کند یا یک مدیر مالی نتواند هزینه API را به یک مشتری خاص نسبت دهد. این چالش‌ها در پیاده‌سازی‌های مشابه نیز دیده شده است؛ برای مثال، پلتفرم BizNode Pulse نیز با جایگزینی جست‌وجوی کلیدواژه‌ای با مدل‌های معنایی تلاش کرد تا دقت بازیابی اطلاعات را در مقیاس سازمانی ارتقا دهد.

محدودیت‌های عملیاتی

این طراحی بر اساس یک نیاز عملیاتی مشخص است: حفظ هویت مهندس (شواهد) و هویت مدیر مالی (مشتری) در تمام مراحل، از لحظه بازیابی تا ثبت نهایی در دفتر کل. این ساختار مانع از آن می‌شود که مدل تظاهر کند متن‌های روان، همان شواهد واقعی هستند.

برای دستیابی به این هدف، سامانه باید تضمین کند که مدل اشیاء استناد را اختراع نمی‌کند. هر تکه بازیابی شده یک شناسه نامفهوم (Opaque ID) دریافت می‌کند. برنامه، شناسه سند و صفحه یا لنگر URL را خارج از بستر (Context) مدل نگه می‌دارد. سامانه تنها شناسه‌هایی را می‌پذیرد که در این لیست مجاز (Allowlist) پیش‌تعریف شده باشند.

مرز سه مرحله‌ای

معماری پیشنهادی برای حفظ مرز میان شواهد و سنتز، فرآیند را به سه مرحله مجزا تقسیم می‌کند:

• مرحله بردار معنایی (Embedding Stage): سامانه برای تیکت ورودی و تکه‌های سند، با استفاده از POST /v1/embeddings بردار ایجاد می‌کند تا پرس‌وجو را برداری کند.
• مرحله جست‌وجوی معنایی (Semantic Search Stage): سامانه کاندیداها را انتخاب می‌کند. در صورت نیاز به بهبود مجموعه کاندیداها و اگر ارزیابی بازیابی ارزش آن را تایید کند، می‌توان یک بازرتبه‌بند (Reranker) اختصاصی مانند Cohere به عنوان یک گام اضافی اضافه کرد.
• مرحله تکمیل گفتگو (Chat Completion Stage): مدل تنها شواهد منتخب را دریافت کرده و باید پاسخی ساختاریافته برگرداند.

پیاده‌سازی گیت استناد

برای جلوگیری از ساخت لینک‌های جعلی یا شماره صفحات ساختگی توسط مدل، سامانه هر تکه بازیابی شده را با یک شناسه نامفهوم علامت‌گذاری می‌کند. برنامه، شناسه واقعی سند و صفحه یا لنگر URL را خارج از دسترس مدل نگه می‌دارد. سپس مدل مجبور است از یک قرارداد کوچک JSON استفاده کند که تنها شامل چهار فیلد است: answer (پاسخ)، confidence (اعتماد)، citations (استنادات) و follow_up_questions (سوالات تکمیلی).

هر استناد باید شامل یک شناسه تکه بازیابی شده باشد که برنامه سپس آن را به متادیتای مورد اعتماد متصل می‌کند. مدل مجاز است توضیح دهد چرا یک بخش خاص اهمیت دارد، اما اکیداً از ساخت URL یا شماره صفحه منع شده است.

به عنوان مثال، برای تیکت acme-18427 اگر بازیابی شناسه‌های refund-policy#p3 و plan-limits#enterprise را برگرداند، یک پاسخ معتبر می‌تواند به هر یک از این شناسه‌ها استناد کند. اما اگر مدل شناسه‌ای مانند refund-policy#p9 را ذکر کند در حالی که فقط refund-policy#p3 ارائه شده بود، مکانیسم «بستن در صورت خطا» (fail closed) فعال می‌شود. این عدم تطابق فوراً تیکت را برای بازبینی انسانی (needs_human_review) علامت‌گذاری می‌کند، به جای اینکه یک پاسخ محتمل اما جعلی را به مشتری ارسال کند.

اعتماد و مسیریابی

در این سامانه، امتیازات اعتماد به عنوان راهنمای مسیریابی (Routing hints) تلقی می‌شوند، نه احتمالات کالیبره شده. از آنجایی که یک آستانه (Threshold) واحد ممکن است در صف‌های مختلف — مانند صف‌های استرداد وجه، امنیت و دسترسی به حساب — به طور یکسان عمل نکند، تیم‌ها باید تیکت‌های برچسب‌دار هر صف را بازپخش (Replay) کنند تا پیش از اجازه دادن به پاسخ برای دور زدن عامل انسانی، نتایج را بسنجند.

تا آن زمان، هر یک از موارد زیر باید وضعیت needs_human_review ایجاد کنند:

• امتیازات اعتماد پایین.
• لیست استناد خالی.
• عدم تطابق استناد با لیست مجاز.

مدیریت هزینه‌های مشتری و انتخاب تامین‌کننده

بسیاری از دردهای عملیاتی از «پراکندگی کلیدها» (Key sprawl) و تطبیق صورت‌حساب‌ها ناشی می‌شود. این راهنما مسیرهای مختلف یکپارچه‌سازی را برای مدیریت این هزینه‌ها مقایسه می‌کند:

• Infrai: بهترین گزینه برای تیم‌هایی که به یک اعتبارنامه و یک صورت‌حساب واحد برای بردارها و گفتگو نیاز دارند. این ابزار اجازه می‌دهد هزینه‌های هر فراخوانی و متادیتای درخواست مستقیماً به شناسه‌ی مشتری (Tenant ID) متصل شود. زمانی که تطبیق صورت‌حساب اصلی‌ترین درد SRE باشد و استفاده از REST ساده برای خنثی کردن وابستگی به زبان برنامه‌نویسی مد نظر باشد، این گزینه مناسب است. در مقابل، برخی رویکردهای افراطی‌تر برای بهینه‌سازی هزینه وجود دارد، مانند تجربه Artwaste.land در حذف کامل هزینه‌های API از طریق انتقال جست‌وجوی معنایی به مرورگر کاربر.
• OpenAI: ترجیح برای تیم‌هایی که رابطه مستقیم با تامین‌کننده مدل را می‌خواهند. در این حالت، ذخیره‌سازی بازیابی و هر بازرتبه‌بند مجزا، تصمیمات یکپارچه‌سازی برنامه هستند و مصرف مدل باید در کنار شناسه‌ی مشتری ثبت شود.
• Anthropic: مناسب برای تیم‌هایی که مستقیماً بر روی Claude استاندارد شده‌اند. در اینجا نیز بردارها و بازیابی نیازمند طراحی مجزا هستند و مصرف مدل باید در کنار شناسه‌ی مشتری ثبت شود.
• Gemini: برای تیم‌هایی که کارهای هوش مصنوعی خود را با APIهای مدل گوگل استاندارد می‌کنند. شواهد بازیابی و تخصیص صورت‌حساب باید در لایه برنامه صریح باشد و مصرف مدل در کنار شناسه‌ی مشتری ثبت شود.
• OpenRouter: ایده‌آل برای تیم‌هایی که لایه دسترسی به مدل‌های متعدد (Multi-model) را در اولویت قرار می‌دهند. کاربران باید متادیتای بازگشتی و رفتار مسیریابی را با نیازهای حسابرسی تطبیق داده و مصرف بازگشتی را با شناسه‌ی مشتری ذخیره کنند.

حفاظ‌های تولیدی و بازگشت (Rollback)

پیش از فعال‌سازی تریاژ خودکار، توصیه می‌شود مجموعه‌ای ثابت از تیکت‌های برچسب‌دار برای بررسی سه سیگنال مجزا بازپخش شوند: بازخوانی بازیابی (Retrieval recall)، اعتبار استناد و نتایج مسیریابی. پاسخی که درست است اما استناد اشتباه دارد، شکست محسوب می‌شود؛ همان‌طور که پاسخی با استناد درست که به صف اشتباه ارسال شده باشد، شکست است.

برای تضمین پایداری، معیارهای زیر باید برای هر مشتری رصد شوند تا نویز یک حساب خاص، میانگین کل را پنهان نکند:

• تعداد پاسخ‌های بدون استناد.
• تعداد استنادهای ناشناخته.
• تعداد خطاهای ۴۲۹ (محدودیت نرخ).
• نرخ بازبینی انسانی.
• هزینه به تفکیک مشتری.

دفترچه راهنما (Runbook) باید بازگشت به نسخه قبل را به امری ساده و خسته‌کننده تبدیل کند. این کار با نگه داشتن آدرس پیکربندی بازیابی قبلی، نسخه‌بندی پرامپت و طرح‌واره JSON و ثبت این نسخه‌ها در هر تصمیم صورت می‌گیرد. اگر استنادهای ناشناخته افزایش یافت، سامانه باید مسیریابی خودکار را متوقف کرده و تیکت‌ها را به بازبینی انسانی برگرداند، در حالی که بسته شواهد را برای تشخیص علت خطا حفظ کند.

اگر هزینه یک مشتری از بودجه تعیین شده فراتر رفت، سامانه باید تعداد کاندیداها را کاهش دهد یا آن مشتری را به بازبینی انسانی منتقل کند، به جای اینکه درخواست‌ها را بی‌صدا دور بریزد. تلاش‌های مجدد (Retries) نیز نیازمند بررسی خاصی هستند: خطای ۴۲۹ باید درخواست را به تأخیر بیندازد و همان شناسه همبستگی تیکت (Correlation ID) را حفظ کند.

پیاده‌سازی فنی در Go

پیاده‌سازی ارائه شده از یک برنامه Go استفاده می‌کند که تیکت و تکه‌های سیاست را به نقطه انتهایی /v1/chat/completions می‌فرستد. این برنامه از یک طرح‌واره JSON سخت‌گیرانه (با additionalProperties: false) استفاده می‌کند تا مدل را مجبور به رعایت فرمت مورد نیاز کند. کد به طور خاص خطاهای HTTP 429 را با رعایت هدر Retry-After در صورت وجود مدیریت می‌کند تا از حلقه‌های تکرار سریع که می‌تواند مشکلات محدودیت نرخ را بدتر کند، جلوگیری شود.

جزئیات کلیدی فنی عبارتند از:

• متغیرهای محیطی: استفاده از AI_API_BASE ،INFRAI_API_KEY و INFRAI_CHAT_MODEL (برگرفته از کاتالوگ فعلی مدل‌ها).
• اعتبارسنجی: هر شناسه تکه بازگشتی پیش از پذیرش پاسخ، در برابر یک نقشه allowed بررسی می‌شود.
• دفتر کل: ثبت رکورد محدود به مشتری شامل tenant_id ،request_id و cost_usd.

به‌روزرسانی‌های تیکت در مراحل پایین‌دست به صورت «تکرارپذیر» (idempotent) طراحی شده‌اند. از آنجایی که یک پاسخ ممکن است پس از تایم‌اوت کلاینت تکمیل شود، سامانه تصمیم تریاژ را تحت یک کلید منحصر‌به‌فرد (ترکیبی از تیکت و نسخه سیاست) می‌نویسد. این کار از تغییر وضعیت تکراری تیکت در محیط‌های توزیع‌شده که تحویل تکراری پیام در آن‌ها عادی است، جلوگیری می‌کند.

این تغییر در طراحی، تمرکز را از مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — به مهندسی سامانه منتقل می‌کند. با تبدیل مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به یک موتور سنتز به جای پایگاه دانش، لایه برنامه کنترل حقیقت را بازپس می‌گیرد. صفحات سیاست قدیمی یا متناقض را نمی‌توان با یک طرح‌واره خروجی سخت‌گیرانه‌تر تعمیر کرد؛ آن‌ها باید در منبع اصلی اصلاح شوند.

گام بعدی شما

برای کسانی که این سیستم را پیاده می‌کنند، اولین اولویت باید ارسال گیت استناد (Citation Gate) باشد. تنها پس از اینکه گیت در تست‌های کاناری با یک گروه کوچک از مشتریان پاک ماند و نتایج با گردش کار فعلی عوامل انسانی مقایسه شد، سامانه باید به مسیریابی خودکار کامل گسترش یابد.

• ابتدا گیت استناد را پیاده‌سازی کنید و در تست‌های کاناری با یک گروه کوچک از مشتریان بررسی کنید.
• نتایج را با گردش کار فعلی عوامل انسانی مقایسه کنید و تنها پس از رسیدن به نرخ خطای پایین، مسیریابی خودکار را گسترش دهید.
• سیستم مانیتورینگ را بر اساس هزینه و نرخ خطای هر مشتری (Tenant) تنظیم کنید تا نشت بودجه یا توهمات گسترده سریعاً شناسایی شوند.

اما مدیریت حافظه در این سیستم‌ها پیچیدگی‌های بیشتری دارد — به تحلیل ما درباره‌ی پروتکل زمینه مدل (MCP) مراجعه کنید.