نتیجهٔ پردازش دسته‌ای را با شناسهٔ هر رکورد تحویل بگیرید

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

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

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

آیا این کار واقعاً فرصت انتظار دارد؟

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

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

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

شناسهٔ پاسخ را از مدل نخواهید

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

مرجع نتیجه‌های دسته‌ای Anthropic صریحاً می‌گوید ترتیب پاسخ‌ها تضمین‌شده نیست و باید آن‌ها را با custom_id تطبیق داد. مستندات ورودی Bedrock نیز دربارهٔ ترتیب خروجی هشدار می‌دهد و فیلد recordId را شرح می‌دهد؛ اگر آن را نفرستید، سرویس در خروجی شناسه می‌افزاید. پیشنهاد ما این است که شناسه را خود برنامه پیش از ارسال بسازد و نگه دارد.

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

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

سه حساب جدا برای پایان کار داشته باشید

توقف پردازش نزد ارائه‌دهنده، روشن‌شدن وضعیت هر درخواست و پذیرفته‌شدن پاسخ در برنامه سه اتفاق متفاوت‌اند. هرکدام باید وضعیت مستقل داشته باشد. اگر برنامه با دیدن پایان کار، همهٔ رکوردها را موفق علامت بزند، عملاً بررسی دو مرحلهٔ بعد را حذف کرده است. مسئول تحویل باید بتواند بگوید کدام حساب بسته شده و کدام هنوز باز است.

این تفاوت در مستندات خروجی Bedrock دیده می‌شود: در سطر ناموفق، شیء error جای modelOutput را می‌گیرد؛ شمارندهٔ processedRecordCount هم موفقیت‌ها و خطاها را با هم می‌شمارد. بنابراین عدد پردازش‌شده، تعداد پاسخ قابل‌استفاده نیست.

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

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

پیش از ارسال، فهرست ورودی را قطعی کنید

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

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

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

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

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

شش سطر برگشته، فقط دو پاسخ پذیرفته‌شده

برای آزمون واردکننده، یک فایل عمداً خراب بسازید. فهرست مرجع شش کلید a تا f دارد، ولی خروجی به ترتیب c, a, b, b, d, x رسیده است. دو پاسخ b با هم اختلاف دارند؛ d خطای ارائه‌دهنده است؛ a و c از بررسی برنامه عبور می‌کنند. تعداد سطرها همچنان شش است.

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

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

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

تطبیق را پیش از ورود به جدول اصلی انجام دهید

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

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

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

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

فقط کار حل‌نشده را دوباره بفرستید

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

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

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

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

سه زمان و چند نسخهٔ داده را مدیریت کنید

موعد کسب‌وکار، فرصت پردازش ارائه‌دهنده و فرصت دریافت نتیجه را جدا ثبت کنید. راهنمای پردازش دسته‌ای Anthropic انقضای ۲۴ساعته برای درخواست‌های هنوز ارسال‌نشده به مدل، دسترسی به نتیجه تا ۲۹ روز از ساخت دسته و واجد شرایط نبودن این روش برای نگهداری صفر داده را بیان می‌کند. این مشخصات همان سرویس است، نه قاعده‌ای مشترک برای Bedrock و Gemini.

برای دریافت و اصلاح، پیش از موعد نهایی حاشیه بگذارید. مثلاً گزارش ساعت ۸ صبح، با ۹۰ دقیقه زمان رزروشده برای تطبیق و بازبینی، باید تا ۶:۳۰ نتیجهٔ قابل‌استفاده داشته باشد. این یک بودجهٔ زمانی فرضی داخلی است، نه تعهد فروشنده. اگر شواهد در موعد داخلی کامل نشد، تأخیر را اعلام کنید یا از سیاست مجاز تحویل جزئی استفاده کنید.

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

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

هزینه و کیفیت را با کار پذیرفته‌شده بسنجید

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

برای تصمیم هزینه، خرج استنتاج، ذخیره‌سازی، دریافت، بازبینی و اصلاح را بر تعداد کارهای یکتای پذیرفته‌شده تقسیم کنید. در یک حساب فرضی، ۶۰ واحد هزینه برای هزار درخواست، ظاهراً ۰٫۰۶ واحد به ازای هر درخواست است. اگر فقط ۷۵۰ کار پذیرفته شوند، همان خرج به ۰٫۰۸ واحد برای هر کار پذیرفته‌شده می‌رسد؛ هنوز هزینهٔ بازیابی بعدی را هم حساب نکرده‌ایم. این اعداد قیمت سرویس یا صرفه‌جویی اندازه‌گیری‌شده نیستند.

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

معیار تحویل را به آزمون تبدیل کنید

واردکننده را با پاسخ‌های جابه‌جا، کلید گم‌شده، کلید ناشناخته، تکرار ناسازگار، سطر ناخوانا، خطای ارائه‌دهنده و پاسخ خوش‌قالب ولی نامقبول آزمایش کنید. همان فایل را دوباره وارد کنید و توقف برنامه میان ذخیرهٔ شاهد و ثبت رأی را نیز بیازمایید. هیچ‌یک از این وضعیت‌ها نباید به انتشار مجموعه‌ای ظاهراً کامل منجر شود.

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

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

یادداشت منابع — بازبینی ۲۰۲۶-۱۱-۱۲

پنج سند رسمی زیر در ۱۲ نوامبر ۲۰۲۶ بررسی شدند. این‌ها مستندات زنده‌اند، نه پنج خبر تازه. مرجع نتیجه‌های Anthropic نسخهٔ رابط ۲۰۲۶-۱۰-۲۱ را نشان می‌داد. طرح تطبیق، نمونهٔ خراب، بودجهٔ زمانی و محاسبهٔ هزینه تحلیل ژرف‌اند؛ ادعای آزمون مقایسه‌ای خدمات یا اجرای واقعی برای مشتری مطرح نشده است.

• پردازش دسته‌ای Anthropic: انقضا، فرصت دریافت و شرایط نگهداری داده.
• رابط نتیجه‌های دسته‌ای Anthropic: شناسهٔ همراه پاسخ و روش تطبیق.
• ورودی دسته‌ای Amazon Bedrock: شناسهٔ رکورد و محدودیت تضمین ترتیب.
• نتیجه‌های دسته‌ای Amazon Bedrock: وضعیت هر رکورد و تعریف شمارنده‌ها.
• رابط دسته‌ای Google Gemini: کلید درخواست فایل‌محور و شرایط اعلام‌شدهٔ هزینه و زمان.