فیچر AI را جادو ندان؛ مرز ابزار را طراحی کن

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

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

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

مدل انتخاب می‌کند؛ اپ وضعیت را نگه می‌دارد

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

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

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

معرفی را از یک درد تکراری شروع کن

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

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

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

سطح کوچک، شاخه پنهان کم

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

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

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

نشانه‌ای که مرز هنوز قاطی است

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

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

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

ابزار را مثل تابع محصول اسم بگذار

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

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

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