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

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

این موقعیت فرضی است، نه گزارشی از مشتری ژرف. مسئله برای سازنده جست‌وجوی سازمانی و مسئول عملیات روشن است: چه زمانی دستیار حق دارد نبودن یک مورد را در محدوده مشخص گزارش کند؟ چه وقت باید جست‌وجو را ادامه دهد یا صریح بگوید هنوز پاسخ را نمی‌داند؟ نقل درستِ فهرست دریافتی کافی نیست؛ باید بدانیم آن فهرست، چه چیزهایی را بررسی‌نشده باقی گذاشته است.

دو صفحه خالی و یک درخواست باز

ابتدا یک نمونه کوچک بسازیم. پنج رکورد با شناسه‌های ۱ تا ۵ در بخش مربوط به یک دستگاه داریم. چهار رکورد نخست بسته‌اند و رکورد پنجم باز است. ابزار در هر نوبت حداکثر دو رکورد را به ترتیب شناسه می‌خواند، سپس فقط موارد باز را نگه می‌دارد. داده در طول آزمون تغییر نمی‌کند و اندازه رکوردها آن‌قدر کم است که سقف حجمی زودتر از سقف دو رکورد فعال نمی‌شود.

اگر شرط حلقه «تا وقتی فهرست خالی نیست» باشد، برنامه همان صفحه اول تمام می‌شود. اگر برنامه وضعیت ادامه را بخواند، به درخواست باز می‌رسد. دو صفحه خالی نه خطای سرویس‌اند، نه شاهد خالی‌بودن کل مجموعه. فقط در همان دو بخشِ خوانده‌شده، موردی از فیلتر عبور نکرده است.

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

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

«وجود ندارد» درباره کدام مجموعه حرف می‌زند؟

وقتی دستیار می‌گوید «قراردادی وجود ندارد»، ممکن است فقط پوشه یک واحد را دیده باشد. شاید اسناد بایگانی‌شده، پیوست‌ها یا نسخه‌های قدیمی در جست‌وجو نبوده‌اند. شاید حساب کاربریِ متصل به ابزار، به بخشی از مخزن دسترسی نداشته است. این محدودیت‌ها حاشیه پاسخ نیستند؛ معنای آن را تعیین می‌کنند.

مجموعه مورد بررسی را از شرط انتخاب جدا بنویسید. برای مثال، مجموعه می‌تواند رکوردهای مجاز تعمیرات یک سایت باشد و شرط، شناسه دقیق دستگاه، وضعیت باز و بازه زمانی مشخص. جست‌وجوی چند واژه مشابه در متن، همان کار نیست؛ حتی اگر هر دو ابزار در گفت‌وگو «جست‌وجوی درخواست» نام داشته باشند.

پیشنهاد ما این است که سه گزاره را از هم جدا کنید: «این مورد را پیدا کردم»، «این پرس‌وجوی مشخص تمام شد و تطبیقی نداشت» و «بررسی هنوز پاسخ را روشن نکرده است». گزاره دوم درباره مخزن متصل‌نشده یا چیزی که اصلاً ثبت نشده، ادعایی ندارد. دامنه را همراه درخواست به ابزار بدهید و در پاسخ نهایی نیز قابل‌فهم نگه دارید.

برای تکمیل جست‌وجو، دسترسی را پنهانی گسترش ندهید. ابزار نباید پس از نتیجه خالی با هویت دیگری، در سازمان دیگری یا در مخزنی خارج از درخواست جست‌وجو کند. اگر خود کاربر هنوز منظورش از «همه قراردادها» را مشخص نکرده، سؤال روشن‌کننده بخشی از کار است. مدل حق ندارد این ابهام را با یک فرض بی‌صدا حل کند.

چرا سرویس سالم، صفحه خالی تحویل می‌دهد؟

مستندات صفحه‌بندی Microsoft Graph می‌گوید یک صفحه ممکن است هیچ نتیجه‌ای نداشته باشد. برای ادامه باید نشانی کامل @odata.nextLink را دنبال کرد تا دیگر برنگردد. در پرس‌وجوهای دایرکتوری، سرآیندهای سفارشی لازم نیز باید در درخواست‌های بعدی دوباره فرستاده شوند. رابطی که فقط ردیف‌ها را نگه می‌دارد، ممکن است هم ادامه و هم بخشی از شرایط درخواست را از دست بدهد.

در مرجع Query در DynamoDB، فیلتر پس از خواندن رکوردها اعمال می‌شود. بنابراین پاسخ خالی می‌تواند همراه LastEvaluatedKey برسد. وجود این کلید تضمین نمی‌کند صفحه بعدی تطبیقی دارد؛ نشان می‌دهد پایان مجموعه هنوز احراز نشده است. همین تفاوت، نمونه پنج‌رکوردی ما را توضیح می‌دهد.

این رفتارها قرارداد همان سرویس‌اند، نه نسخه‌ای یکسان برای همه رابط‌ها. برنامه را با طول فهرست، کوتاه‌ترشدن صفحه از اندازه درخواستی یا احساس اطمینان مدل متوقف نکنید. هر رابط باید علامت پایانِ مستند خودش را بفهمد. در مقابل، ادامه‌دادن نامحدود هم درست نیست؛ تمام‌شدن بودجه زمان یا درخواست، یک نتیجه ناتمام و قابل‌گزارش است.

مسئول صفحه بعدی، رابط اتصال باشد نه مدل

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

برای هر اجرا، منبع، زمینه هویت مجاز، صورت نهایی پرس‌وجو، فیلترها، ترتیب، دامنه درخواستی، زمان شروع و شناسه نمای زمانی منبع را ــ اگر وجود دارد ــ ثبت کنید. توکن خام ادامه و اعتبارنامه جایگاهی در متن مدل ندارند. دستیار معمولاً به شناسه اجرا و وضعیت قابل‌اعتماد نیاز دارد، نه جزئیات ارسال درخواست.

رابط باید ساختار پاسخ را بررسی کند، وضعیت ادامه مخصوص سرویس را نگه دارد و رکوردها را با شناسه پایدار جمع کند. تکرار بی‌پیشرفتِ وضعیت ادامه را تشخیص دهد و برای مجموع صفحه‌ها، زمان و حجم خواندن سقف بگذارد. دلیل پایان را جدا برگرداند: پایان واقعی، اتمام بودجه، خطای منبع، دامنه ناقص یا ازدست‌رفتن نمای زمانی. همه این حالت‌ها را زیر یک برچسب «موفق» پنهان نکنید.

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

این معماری پیشنهاد ژرف برای اتصال ابزار است، نه قابلیتی تضمین‌شده در همه محصولات نام‌برده. هدفش این است که کار ناتمام دیده شود و در عین حال جزئیات فنی، پرسش ساده کاربر را اشغال نکند.

پایان صفحه‌ها با کامل‌بودن جست‌وجو یکی نیست

پاسخ موفق شبکه پایان بررسی نیست. در مرجع نسخه سوم Google Drive، nextPageToken و incompleteSearch دو نشانه جدا هستند. دومی می‌گوید بخشی از اسناد جست‌وجو نشده‌اند؛ برای مثال ممکن است جست‌وجوی چند درایو ناقص بماند. مصرف‌کردن همه صفحه‌های موجود این محدودیت را برطرف نمی‌کند. کوچک‌کردن دامنه هم دامنه ادعای نهایی را عوض می‌کند.

رابط جست‌وجوی Elasticsearch نیز نتیجه جزئی، خطای بخش‌های جست‌وجو و پایان مهلت را گزارش می‌کند. وقتی timed_out درست باشد، نتیجه می‌تواند ناقص یا خالی باشد. مسیر پاسخ منفی باید این نشانه‌ها را بخواند؛ قابل‌خواندن‌بودن پاسخ، گواه کامل‌بودن آن نیست.

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

داده ممکن است میان دو صفحه جابه‌جا شود

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

راهنمای صفحه‌بندی Elasticsearch استفاده از search_after همراه نمای نقطه‌ای در زمان را توضیح می‌دهد. ترتیب باید تکلیف مقدارهای برابر را روشن کند و معنای پرس‌وجو و مرتب‌سازی در ادامه حفظ شود. این حفاظت مربوط به همان نمایه است؛ کامل‌بودن اسناد بالادستی را ثابت نمی‌کند.

مرز در پایگاه داده شکل دیگری دارد. طبق مستندات جداسازی تراکنش PostgreSQL 18، در حالت Read Committed هر دستور نمای تازه‌ای می‌بیند. خواندن‌های پی‌درپی در یک تراکنش Repeatable Read از نمای مشترکِ زمان نخستین دستور غیرکنترلی استفاده می‌کنند. هیچ‌کدام برای چند خدمت مستقل، نمای مشترک نمی‌سازند.

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

در راهنمای معنای زمان در داده، زمان منبع، مشاهده و تصمیم را جدا کرده‌ایم. اینجا همین جداسازی، مدت اعتبار پاسخ منفی را محدود می‌کند. بررسی کامل ساعت نه، ثابت نمی‌کند در ساعت نه‌ویک دقیقه رکوردی ساخته نشده است. ذکر زمان فقط زیباسازی پاسخ نیست؛ بخشی از ادعاست.

چند متن مرتبط، فهرست همه شواهد نیست

دستیار متصل به پایگاه دانش معمولاً چند قطعه با رتبه بالا می‌گیرد. اگر متن و اعتبار منبع بررسی شود، این قطعه‌ها شاید برای یک ادعای مثبت کافی باشند. اما سکوت آن‌ها نشان نمی‌دهد که استثنا، اصلاحیه یا پرونده مخالفی در جای دیگر وجود ندارد.

دو کار را از هم جدا کنید: «شاهد مفید پیدا کن» و «همه رکوردهای مطابق این شرط را فهرست کن». اولی گاهی با رسیدن به شاهد کافی تمام می‌شود. دومی مجموعه مشخص و شرط دقیق یا مستقلاً ارزیابی‌شده می‌خواهد. بیشترکردن تعداد قطعه‌های بازیابی‌شده، فرصت یافتن شاهد را بیشتر می‌کند؛ جست‌وجوی رتبه‌بندی‌شده را خودکار به بررسی جامع تبدیل نمی‌کند.

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

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

پاسخ را به اندازه شاهد بنویسید

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

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

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

پاسخ‌های منفی را هم موضوع آزمون قرار دهید

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

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

در مجموعه کوچکِ تحت مالکیت خود، شناسه تطبیق‌های مورد انتظار را مستقل تعیین کنید و با خروجی مقایسه کنید. متن نهایی دستیار نیز جزئی از آزمون پذیرش باشد تا قیدهای پاسخ هنگام خلاصه‌سازی حذف نشوند. برای گزارش فنی، شناسه اجرا، نسخه پرس‌وجو، ارجاع دامنه، تعداد صفحه، دلیل توقف و مرز زمانی کافی را نگه دارید. همه اسناد بازیابی‌شده را بی‌دلیل در گزارش خطا کپی نکنید؛ همین گزارش‌ها هم دسترسی و مدت نگهداری مشخص می‌خواهند.

سهم پاسخ‌های منفی با شاهد تکمیل کافی، علت بررسی‌های ناتمام، تکرار نشانگر و موارد معلومِ ازدست‌رفته در آزمون را دنبال کنید. هزینه و تأخیر را کنار آن‌ها بسنجید. تا وقتی فرایندی مستقل حقیقتِ موارد جاافتاده را روشن نمی‌کند، نرخ واقعی «نبودنِ اشتباه» را تبلیغ نکنید.

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

یادداشت منابع — بررسی‌شده در ۲۳ سپتامبر ۲۰۲۶

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

• صفحه‌بندی Microsoft Graph — به‌روزرسانی ۳ آوریل ۲۰۲۵؛ ادامه و صفحه خالی.
• فهرست فایل‌ها در Google Drive v3 — به‌روزرسانی ۷ ژوئیه ۲۰۲۶؛ دامنه و اعلام جست‌وجوی ناقص.
• پرس‌وجوی DynamoDB — مرجع زنده بدون تاریخ انتشار مشخص؛ فیلتر و نشانه ادامه.
• صفحه‌بندی Elasticsearch — راهنمای زنده بدون تاریخ انتشار مشخص؛ پیمایش پایدار و نمای نقطه‌ای در زمان.
• رابط جست‌وجوی Elasticsearch — مرجع زنده بدون تاریخ انتشار مشخص؛ نتیجه جزئی و پایان مهلت.
• جداسازی تراکنش PostgreSQL 18 — مستندات نسخه‌دار، نه نتیجه پژوهش تاریخ‌دار؛ نمای دستور و تراکنش.