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