بیشتر تیم‌های SaaS جعبه چت می‌خواهند چون جعبه چت دیده می‌شود. محصول مفید معمولاً جای دیگری است: دسته‌بندی تیکت پشتیبانی، پیش‌نویس خلاصه حساب، بیرون کشیدن فیلد فاکتور، مرور PR، آماده کردن برنامه آشناسازی، یا تبدیل ورودی درهم کاربر به کار ساخت‌یافته. یکپارچه‌سازی AI از پیدا کردن همان گردش کار شروع می‌شود و از اینکه امن‌تر، سریع‌تر، یا ارزان‌ترش کنی.
رابط چت هنوز می‌تواند سطح درست باشد. معماری نیست. معماری مسیر است از قصد کاربر تا دسترسی به داده، صدا زدن مدل، اجرای ابزار، تأیید، ذخیره، تلاش دوباره، و اندازه‌گیری. اگر این مسیر مبهم باشد، فیچر در دمو چشمگیر است و در پروداکشن گران.
یک کار با شرط خروج واقعی
اولین فیچر AI باید کار قابل اندازه‌گیری داشته باشد. «به کاربر کمک کن داده‌اش را بفهمد» بیش از حد پهن است. «پیش‌نویس خلاصه هفتگی سلامت حساب از مصرف، تیکت، و رویداد صورتحساب» مشخص است. ورودی دارد، شکل خروجی دارد، انتظار بازبینی دارد، و می‌شود کیفیت را در طول زمان مقایسه کرد.
کارهای خوب اول پرتکرار، آزاردهنده، و محدودند. از داده‌ای استفاده می‌کنند که محصول از قبل مالکش است. یک قدم بازبینی را تحمل می‌کنند. خروجی ساخت‌یافته می‌دهند که بشود پذیرفت، ویرایش کرد، یا رد کرد. لازم نیست مدل پنهانی هم‌زمان مدیر محصول و وکیل و مدیر پایگاه داده شود.
برای همین خروجی ساخت‌یافته مهم است. گردش کار SaaS معمولاً وضعیت، دلیل، توصیه، یک باند اطمینان، و ارجاع به رکورد مبدأ می‌خواهد. نثر آزاد برای انسان مفید است. اپلیکیشن به فیلدی نیاز دارد که اعتبار و ذخیره کند.
شرط خروج را قبل از پرامپت بنویس. خلاصه یا پذیرفته می‌شود، یا با ویرایش ذخیره می‌شود، یا رد می‌شود و دلیل رد در محصول می‌ماند. اگر هیچ‌کدام از این سه را نداری، هنوز کار نداری. یک متن داری که کسی باید دستی تفسیر کند.
ابزار باید مجوز کوچک‌تر از انسان داشته باشد
انسان پشتیبانی ممکن است کل حساب مشتری را ببیند. ابزار AI معمولاً کمتر لازم دارد. به ابزار ورودی باریک بده: شناسه مشتری، محدوده مجاز، شناسه رکورد، و فیلد خاص همان عمل. بگذار سرور بعد از چک مجوز داده خصوصی را بیاورد. رکورد کامل را فقط چون در پروتوتایپ کار می‌کند داخل پرامپت نچسبان.
همین قاعده برای عمل نوشتنی است. مدل می‌تواند یادداشت بازپرداخت پیشنهاد کند، ولی ابزار صورتحساب باید سقف، یکبارمصرف بودن، و تأیید را اجرا کند. مدل می‌تواند تیکت را طبقه‌بندی کند، ولی ابزار تیکت باید تصمیم بگیرد آن طبقه‌بندی حق دارد اولویت را عوض کند یا نه. اسکیمای ابزار سیاست محصول است. با آن همین‌طور رفتار کن.
در بک‌اند TypeScript اینجا جای استفاده تهاجمی از اسکیماست. خروجی مدل را اعتبار کن. ورودی ابزار را اعتبار کن. نتیجه ذخیره‌شده را اعتبار کن. همان چند خط از دیباگ شیء بدشکلی که از سه صف و دو تلاش دوباره رد شده ارزان‌تر است.
شناسه را از مدل نگیر و کورکورانه به کوئری نده. مدل می‌تواند پیشنهاد کند کدام رکورد مرتبط است. سرور باید ثابت کند همان کاربر حق دیدن آن رکورد را دارد. اگر این چک بعد از مدل باشد، مدل تبدیل به لایه مجوز شده و این بدترین جا برای مجوز است.
هزینه مال طراحی است
فیچر AI وقتی می‌میرد که هزینه بعد از انتشار کشف شود. از اول یک شیء بودجه در گردش کار بگذار: مدل، سقف توکن، مهلت، حد تلاش دوباره، سیاست کش، و رفتار جایگزین. اگر کار می‌تواند ناهم‌زمان باشد، از مسیر درخواست بیرونش کن. اگر نتیجه را می‌شود به ازای مشتری یا نسخه سند کش کرد، کش کن. اگر مدل ارزان‌تر طبقه‌بندی را جمع می‌کند و مدل قوی‌تر فقط برای جمع‌بندی نهایی لازم است، کار را بشکن.
این بهینه‌سازی زودرس نیست. طراحی محصول است. فیچری که اجرایش بیش از حد گران است محدود، پنهان، یا حذف می‌شود. فیچری که کنترل بودجه را نشان می‌دهد می‌تواند استفاده واقعی را تاب بیاورد.
واحد را با کسب‌وکار میزان کن. هزینه هر خلاصه پشتیبانی تولیدشده. هزینه هر سند پردازش‌شده. هزینه هر توصیه پذیرفته‌شده. جمع توکن برای مهندس مفید است. تصمیم محصول به هزینه‌ای نیاز دارد که به پیامد گره خورده باشد. اگر توصیه رد شد، آن هزینه را جدا ببین. ارزان بودن تولید مهم نیست اگر نرخ پذیرش نزدیک صفر است.
ارزیابی همان تست رگرسیون قضاوت است
برای شروع لازم نیست آزمایشگاه تحقیق داشته باشی. حدود بیست نمونه واقعی، ویژگی مورد انتظار، و حالت شکست را نگه دار. قبل از عوض کردن سیستم، پرامپت و مدل و ابزار فعلی را روی آن‌ها اجرا کن. ببین جواب منبع درست را استفاده کرده، سیاست را رعایت کرده، JSON معتبر داده، و از عمل بد شناخته‌شده دوری کرده یا نه.
هدف کامل کردن کیفیت نیست. هدف این است که تغییر را کور نفرستی. بدون مجموعه کوچک ارزیابی، هر ویرایش پرامپت آزمایش پروداکشن است. با یکی، تیم می‌تواند مدل، پرامپت، قاعده بازیابی، و توضیح ابزار را با خرافات کمتر عوض کند.
یکپارچه‌سازی وقتی ارزش پیدا می‌کند که داخل گردشی ناپدید شود که کاربر از قبل به آن اهمیت می‌دهد. جعبه چت ممکن است نقطه ورود باشد. برد محصول مسیر قابل اتکا پشت آن است: ابزار باریک، خروجی معتبر، سقف هزینه، تأیید، و اندازه‌گیری کافی برای بهتر کردن بدون حدس.
پشتیبانی باید بتواند همان مسیر را برای یک مشتری باز کند. کدام ابزار صدا زده شد، کدام فیلد رد شد، تأیید مال کی بود. اگر این را فقط در لاگ مدل داری و در محصول نه، حادثه تبدیل به بحث سلیقه می‌شود. گردش کار بدون این رد، دموی گران است.
جعبه چت را آخرین تصمیم بگیر
وقتی مسیر از قصد تا ذخیره روشن شد، تازه بپرس کاربر اصلاً باید بنویسد یا نه. خیلی از کارهای SaaS دکمه مشخص‌تری دارند: «خلاصه این حساب را بساز»، «این فاکتور را بخوان»، «پیش‌نویس جواب این تیکت». چت وقتی حق دارد وسط باشد که قصد واقعاً باز است و بقیه محصول نمی‌تواند آن را در فرم بگذارد. اگر فرم می‌تواند، چت فقط فیلدهای اجباری را قایم می‌کند.
خروجی ساخت‌یافته را به همان دکمه گره بزن. کاربر حاصل را در سطح محصول می‌بیند: وضعیت، دلیل، رکوردهای مرجع. نثر مدل می‌تواند کنارش باشد، ولی منبع حقیقت فیلد است. اگر کاربر فقط حباب چت ببیند و سیستم از همان متن وضعیت بسازد، فردا با یک ویرایش جزئی وضعیت غلط ذخیره می‌شود.
تأیید را برای عمل نوشتنی ارزان نکن و برای خواندن گران نکن. خواندن باریک بعد از چک مجوز سرور معمولاً تأیید جدا نمی‌خواهد. نوشتن روی پول، اولویت، یا دسترسی چرا. اگر هر دو را یک شکل تأیید بگیری، کاربر خسته می‌شود و کلیک را عادت می‌کند. آن‌وقت تأیید دیگر کنترل نیست.
هزینه را در همان صفحه داخلی که کیفیت را مرور می‌کنی بیاور. جدایی داشبورد توکن از مجموعه ارزیابی یعنی دو جلسه که هیچ‌وقت به هم نمی‌رسند. یک جدول کوچک کافی است: این کار چند بار اجرا شد، چند بار پذیرفته شد، چند بار اعتبار شکست، و آیا به صف رفت یا در مسیر درخواست ماند. عدد مالی دقیق برای شروع لازم نیست. شکل روند برای تصمیم نگه داشتن یا شکستن کار کافی است.