تصور کنید بیماری می‌خواهد وقت ملاقات خود با متخصص قلب را برای سه‌شنبه آینده تغییر دهد؛ در این لحظه، یک پاراگراف «مشابه» از سال گذشته هیچ ارزشی ندارد و تنها سیاست‌های جاری زمان‌بندی اهمیت دارند. برای حل این مشکل، Infrai و سایر معماری‌های بازیابی در حال حرکت به سمت «قرارداد بازیابی» هستند؛ جایی که مرزهای ایمنی — و نه فقط میزان مرتبط بودن — تعیین‌کننده پاسخ نهایی هستند.
در محیط‌های حساس پزشکی، یک پاسخ اشتباه صرفاً یک توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — نیست، بلکه یک شکست عملیاتی یا بالینی است. اکثر سامانه‌های تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — بر پایه شباهت کسینوسی (Cosine Similarity) کار می‌کنند. این رویکرد اغلب اسناد قدیمی را صرفاً به دلیل شباهت کلمات به پرسش، در اولویت قرار می‌دهد. این موضوع یک شکاف خطرناک ایجاد می‌کند که در آن یک سیاست حذف‌شده ممکن است همچنان رتبه‌ای بالاتر از نسخه جاری داشته باشد. برای یک دستیار تعیین وقت پزشکی، رتبه‌بندی پیش از آنکه یک ترفند برای افزایش مرتبط بودن باشد، در واقع یک مرز ایمنی است.
به نقل از یک راهنمای فنی منتشر شده در ۷ اکتبر ۲۰۲۶، راهکار جایگزین، تبدیل جست‌وجوی برداری ساده به یک فرآیند بازیابی مرحله‌ای است. در این مدل، رتبه‌بندی به عنوان یک مرز ایمنی تعریف می‌شود. به‌جای اینکه امیدوار باشیم مدل بازرتبه‌بندی (Reranker) متوجه تاریخ منقضی‌شده شود، سیستم پیش از هرگونه امتیازدهی معنایی، گیت‌های سخت‌گیرانه‌ای را اعمال می‌کند. قرارداد بازیابی دقیقاً تعریف می‌کند که کدام واقعیت‌ها مورد نیاز هستند، میزان تازگی آن‌ها چقدر باید باشد و دستیار باید چه شواهدی را برای پاسخ بازگرداند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دقیق ورودی‌ها تنها راه کاهش خطاهای بحرانی است.
گردش‌کار بازیابی مرحله‌ای
این معماری برای تضمین یکپارچگی داده‌ها از یک توالی سخت‌گیرانه پیروی می‌کند. فرآیند عملیاتی شامل جست‌وجو در یک منبع وب محدود یا منبع سیاست‌های جاری برای یافتن مطالب به‌روز، و سپس استعلام از یک مجموعه ایندکس‌شده برای محتوای تأییدشده محصول است. در نهایت، کاندیداها در یک زمینه محدود و مستند برای مدل پاسخ‌دهنده ادغام می‌شوند:
- گیت‌های سخت: سیستم ابتدا بر اساس مستاجر (Tenant)، مکان (Locale)، نوع نوبت و تاریخ اجرا فیلتر می‌کند. برای مثال، اگر کاربر درباره قلب سؤال کند، سیاست‌های مربوط به تصویربرداری فوراً حذف می‌شوند، حتی اگر کلمات مشابهی داشته باشند.
- اعتبارسنجی و دامنه: سیستم بررسی می‌کند که آیا رکورد فعال است و آیا تاریخ درخواستی در بازه زمانی مجاز (Effective Window) رکورد قرار دارد یا خیر. همچنین اطمینان حاصل می‌کند که کلینیک، تخصص، طرح بیمه و کانال ارتباطی بیمار با پرس‌وجو مطابقت دارد.
- اولویت تازگی: در صورت برابر بودن اعتبار و دامنه، جدیدترین محتوای تأییدشده برنده است. این کار از نوسانات «دفترچه-به-تولید» (notebook-to-prod) جلوگیری می‌کند، جایی که فایل‌های PDF قدیمی در ایندکس باقی می‌مانند.
- امتیازدهی معنایی: بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که همسایگی آن با کلمات دیگر را می‌گوید — تنها برای مرتب‌سازی کاندیداهایی استفاده می‌شود که پیش‌تر از گیت‌های ایمنی عبور کرده‌اند.
- کیفیت شواهد: سیستم اولویت را به منابعی می‌دهد که دارای شناسه‌های پایدار، مالکان مشخص و برچسب‌های زمانی بازبینی (Revision Timestamps) هستند.
پیاده‌سازی فنی و ردیابی
برای حفظ این قرارداد، ردپای بازیابی (Retrieval Trace) باید به عنوان یک موجودیت درجه اول در نظر گرفته شود. سیگنال‌هایی مثل اعتبار، دامنه، تازگی، امتیاز معنایی و کیفیت شواهد به عنوان فیلدهایی در ردپای بازیابی ذخیره می‌شوند. این ساختار اجازه می‌دهد یک ابزار ارزیابی به‌جای گزارش یک امتیاز کسینوسی پایین و مبهم، عبارت «عدم تطابق دامنه» (Scope Mismatch) را نمایش دهد.
هر تکه متن (Chunk) بازگردانده شده باید دارای URL منبع یا شناسه سند و برچسب زمانی بازیابی باشد. اگر دستیار نتواند منبع خود را ذکر کند، سیستم به‌گونه‌ای طراحی شده است که به‌جای تخمین زدن و بداهه پردازی، درخواست شفاف‌سازی کند یا کاربر را به اپراتور انسانی ارجاع دهد.
در یک پیاده‌سازی عملی با پایتون و استفاده از Infrai، سیستم دو مسیر جست‌وجوی تأییدشده را فراخوانی می‌کند: /v1/web/search (محدود به ۵ نتیجه) و /v1/vector/query (۸ نتیجه برتر یا top_k=8) و سپس کاندیداها را ادغام می‌کند. کد شامل مدیریت صریح محدودیت‌های نرخ درخواست (HTTP 429) با پشتیبانی از هدر Retry-After است. اگر هدر Retry-After موجود نباشد، سیستم از یک عقب‌نشینی نمایی (Exponential Backoff) با فرمول 2**attempt تا سقف ۸.۰ ثانیه استفاده می‌کند تا درخواست بیمار به‌دلیل کندی منبع، متوقف نشود.
مدیریت چرخه حیات ایندکس
در این معماری، تازگی داده‌ها به عنوان یک گردش‌کار ایندکس‌گذاری دیده می‌شود، نه یک وزن رتبه‌بندی. یک وزن رتبه‌بندی نمی‌تواند یک سیاست حذف‌شده را زنده کند. بنابراین موارد زیر الزامی است:
- شناسه‌های پایدار: هر رکورد منبع یک ID دائمی و برچسب زمانی بازبینی دارد. با تغییر محتوا، سیستم تکه جدید و متادیتای آن را به‌روزرسانی (Upsert) می‌کند.
- رویدادهای حذف صریح: هنگام حذف محتوا، شناسه آن در جریان استقرار (Deployment Workflow) از مجموعه پاک می‌شود. یک پنجره هم‌پوشانی کوتاه در زمان باز-ایندکس‌گذاری حفظ می‌شود، اما مرحله پاسخ‌دهی تنها رکوردهایی را انتخاب می‌کند که علامت «فعال» دارند.
- تست‌های تاریخ‌محور: آزمایش‌ها با داده‌های تاریخ‌دار (Dated Fixtures) انجام می‌شود تا پنجره تازگی به‌جای حدس و گمان، اندازه‌گیری شود، زیرا سیاست‌های کلینیک و چرخه‌های بازبینی رگولاتوری با هم متفاوت هستند.
این رویکرد مشکل رایج باقی ماندن PDFهای قدیمی را حل می‌کند. راهکار، یک شغل جذب داده (Ingestion Job) با رویدادهای حذف صریح و تأییدیه «تازگی تا تاریخ X» در تست‌ها است. این شغل ثبت می‌کند چه کسی بازبینی را تأیید کرده، کدام مستاجر آن را دریافت کرده، کدام تکه‌ها جایگزین شده‌اند و دقیقاً از کدام نسخه مجموعه (Collection Revision) برای یک پاسخ استفاده شده است. اگرچه بازسازی کامل شبانه یک پشتیبان مفید است، اما نمی‌تواند تنها مکانیسم باشد، به‌خصوص زمانی که تغییر سیاست در همان روز بر بیماران تأثیر می‌گذارد.
مقایسه زیرساخت‌ها
انتخاب بک‌اند عملیات را تغییر می‌دهد اما قرارداد بازیابی را نه. توسعه‌دهندگان باید مجموعه‌های ارزیابی یکسانی را که بر اساس تاریخ و مستاجر محدود شده‌اند، روی گزینه‌های زیر اجرا کنند:
- Elasticsearch: برای کنترل‌های عمیق درون‌سازمانی (On-prem)، فیلترهای بالغ، تحلیل‌گرها و پرس‌وجوهای ترکیبی لکسیکال/برداری در یک کلاستر توصیه می‌شود. نقطه ضعف آن، نیاز به مدیریت بیشتر عملیات کلاستر و اسکیما است.
- Pinecone: یک ایندکس برداری مدیریت‌شده با سطح عملیاتی متمرکز است. فیلترینگ متادیتا و رفتار تازگی در این سیستم نیازمند اعتبارسنجی دقیق است.
- Weaviate: دارای اسکیمای بردار-محور با جست‌وجوی ترکیبی و ماژول‌های مختلف است. انتخاب ماژول‌ها می‌تواند تصمیمات مربوط به استقرار و ارتقا را پیچیده کند.
- Infrai: یک سطح REST پایدار فراهم می‌کند که اجازه می‌دهد تیم‌ها بدون بازنویسی لایه پایتون، بک‌اند خود را تعویض کنند. این برای تیم‌های کوچک B2B SaaS که چندین ارائه‌دهنده دارند ارزشمند است، هرچند برای کسانی که نیاز به تنظیم دستی تک‌تک اجزای ایندکس دارند مناسب نیست.
بررسی‌های عملیاتی و ایمنی
پیش از عرضه، سیستم باید فیلترهای مستاجر و تخصص، سقف زمان پرس‌وجو و حداکثر اندازه زمینه (Context Size) را تأیید کند. تست‌ها باید شامل موارد زیر باشد: یک سیاست تغییریافته، یک سیاست حذف‌شده و دو سیاست با کلمات تقریباً یکسان اما تاریخ‌های اجرای متفاوت.
قوانین عملیاتی شامل نگه داشتن تلاش‌های مجدد (Retries) خارج از حلقه مدل است. یک خطای 429 باید باعث عقب‌نشینی شود، در حالی که خطاهای 4xx باید برای فراخواننده و در ردپای سیستم قابل مشاهده باشند. شناسه‌های درخواست (Request IDs) و ویژگی‌های رتبه‌بندی بدون ذخیره متون غیرضروری بیمار، لاگ می‌شوند.
این تغییر رویکرد، هوش مصنوعی را از «حدس احتمالی» به «بازیابی قطعی» تبدیل می‌کند. با ثبت اینکه چه کسی بازبینی را تأیید کرده و کدام تکه‌ها جایگزین شده‌اند، توسعه‌دهندگان می‌توانند دقیقاً حسابرسی کنند که چرا یک پاسخ خاص به بیمار داده شده است.
برای کسانی که این سیستم‌ها را مستقر می‌کنند، بررسی نهایی باید یک بازبینی بالینی باشد. سیگنال رتبه‌بندی درست، سیگنالی است که از بازبینی مالکان زمان‌بندی عبور کند، نه آنکه در یک بنچمارک عمومی برنده شود.
گام بعدی شما
- اگر از RAG استفاده می‌کنید، بررسی کنید آیا سیستم شما اسناد قدیمی را صرفاً به‌دلیل شباهت کلمات در اولویت قرار می‌دهد یا خیر.
- یک لایه فیلترینگ سخت (Hard Gate) بر اساس تاریخ یا وضعیت فعال/غیرفعال پیش از مرحله امتیازدهی معنایی اضافه کنید.
- برای هر پاسخ تولید شده، یک ردپای بازیابی (Retrieval Trace) شامل شناسه منبع و زمان بازبینی ایجاد کنید تا قابلیت حسابرسی فراهم شود.
اما تأثیر این دقت در بازیابی بر کاهش هزینه‌های استنتاج حتی چشمگیرتر است — به تحلیل ما درباره بهینه‌سازی توکن‌ها در مدل‌های استدلالی مراجعه کنید.
گفتگو