اگر «ساخت ایجنت هوش مصنوعی» را جستجو کنید، صفحهٔ اول تقریباً یکدست است: آموزشهای n8n، «در پانزده دقیقه بساز»، «بدون کدنویسی».
میخواهم چیزی بگویم که شاید انتظارش را ندارید: آن آموزشها درستاند. واقعاً میشود در یک بعدازظهر چیزی ساخت که کار میکند. من خودم توصیه میکنم این کار را بکنید — سریعترین راه فهمیدن اینکه این فناوری چیست، ساختن یکی است.
مسئله جای دیگری است. مسئله فاصلهٔ بین آن چیزی است که در ویدیو کار میکند و آن چیزی که سه ماه بعد، با صد مشتری واقعی، هنوز کار میکند.
این نوشته دربارهٔ همان فاصله است — پنج شکافی که در نمونهٔ نمایشی اصلاً دیده نمیشوند، چون فقط زیر بار واقعی ظاهر میشوند.
شکاف اول: حافظه فقط تا آخر همان گفتگو
در نمونهٔ نمایشی، شما یک پیام میفرستید و پاسخ میگیرد. عالی است.
حالا پنجره را ببندید، فردا برگردید و بنویسید «همان که دیروز گفتم». سیستم نمیداند از چه حرف میزنید.
بیشتر ابزارهای بدون کدنویسی حافظهٔ گفتگو دارند — یعنی چند پیام آخرِ همین نشست را نگه میدارند. آنچه ندارند حافظهٔ شخص است: پروندهای که بگوید این آدم کیست، سه هفته پیش چه پرسید، و کجا متوقف شد.
برای یک ربات پاسخگو به پرسشهای عمومی، این مهم نیست. برای فروش، تعیینکننده است: فروش در یک نشست تمام نمیشود.
چه چیزی میبندَدش: یک پایگاه دادهٔ بیرونی که به شناسهٔ شخص کلید بخورد، نه به شناسهٔ گفتگو. کار سختی نیست، ولی تصمیمی است که باید از روز اول گرفته شود — چون بعداً یعنی بازنویسی.
شکاف دوم: هیچ حدی برای گفتن نیست
نمونهٔ نمایشی را با پرسشهای مؤدبانه امتحان میکنید و خوب جواب میدهد. مشتری واقعی میپرسد «چقدر تخفیف میدهید؟» و سیستم — چون میتواند حرف بزند — چیزی میگوید.
در آموزشها این را با یک جمله در متن دستور حل میکنند: «قیمت نده». این کار میکند تا روزی که کسی اصرار کند یا جملهای بنویسد که سیستم را از آن قاعده منحرف کند.
حد واقعی وقتی معنا دارد که در سازوکار باشد: سیستم اصلاً به فهرست قیمت دسترسی نداشته باشد. چیزی که ندارد را نمیتواند بگوید.
چه چیزی میبندَدش: جدا کردن آنچه سیستم میداند از آنچه اجازه دارد بگوید — دو چیز متفاوت که در نمونهٔ نمایشی یکی به نظر میرسند.
شکاف سوم: وقتی مدل جواب نمیدهد
سرویس مدل کند میشود، سهمیه تمام میشود، یا خطا برمیگرداند. در نمونهٔ نمایشی این اتفاق نمیافتد چون دو بار امتحانش کردهاید.
در کار واقعی هفتهای چند بار پیش میآید، و آنچه در آن لحظه رخ میدهد تعیینکننده است. سه رفتار ممکن است:
- بدترین: سیستم چیزی میگوید که نباید — پاسخ ناقص یا بیربط
- بد: سکوت. مشتری منتظر میماند و میرود
- درست: یک جملهٔ روشن، و پروندهای که صبح روی میز کسی باشد
چه چیزی میبندَدش: تعیین اینکه در حالت خرابی چه میشود — کاری که پنج دقیقه طول میکشد و تقریباً هیچ آموزشی به آن نمیپردازد، چون در ویدیو دیده نمیشود.
شکاف چهارم: هر کانال یک ربات جدا
آموزش را برای تلگرام دنبال میکنید. جواب میدهد. بعد واتساپ را میخواهید، دوباره میسازید. بعد سایت.
سه ماه بعد سه سیستم دارید که سه چیز متفاوت میگویند، چون هر بار که قاعدهای عوض شده در یکیشان جا افتاده. و مشتری دقیقاً از همان کانالی میآید که یادتان رفته.
چه چیزی میبندَدش: یک هستهٔ منطق و چند لایهٔ نازک برای اتصال به کانالها. این یک تصمیم معماری است، نه یک ویژگی — و بعد از اینکه سه ربات ساختید، اصلاحش گران است.
چرا این شکاف بیشتر از بقیه دیده نمیشود
چون خرابی مدل در ساعتهایی اتفاق میافتد که کسی نگاه نمیکند. اگر سیستم ساعت سه بامداد پاسخ عجیبی بدهد یا ساکت بماند، فردا هیچ نشانهای از آن نیست — نه شکایتی، نه خطایی در گزارش. فقط یک مشتری که دیگر پیام نداد، و شما هرگز نفهمیدید بوده.
راهش هم ساده است: هر خطا باید جایی ثبت شود که فردا صبح خوانده شود. نه گزارش پیچیده — یک فهرست از گفتگوهایی که به نتیجه نرسیدند، با دلیلش.
شکاف پنجم: بهروزرسانی یعنی بازسازی
محصولی اضافه میشود. قاعدهای عوض میشود. در نمونهٔ نمایشی، این یعنی برگردید و متن دستور را دستکاری کنید.
مشکل این است که دانش و رفتار در یک جا نوشته شدهاند. هر بار که میخواهید سیستم چیز جدیدی بداند، در همان متنی دست میبرید که تعیین میکند چطور حرف بزند. نتیجه: هر بهروزرسانی میتواند لحن یا محدودیتها را خراب کند، و کسی متوجه نمیشود تا وقتی مشتری چیزی عجیب بگیرد.
چه چیزی میبندَدش: دانش در یک جا که قابل بهروزرسانی باشد، رفتار در جای دیگر که ثابت بماند.
عملاً یعنی: فهرست محصولات، قیمتها و قاعدهها در فایلی که هر کسی میتواند ویرایشش کند، و شخصیت و محدودیتهای سیستم در جایی که فقط با تصمیم عوض میشود. کسی که میخواهد محصول جدید اضافه کند، نباید هرگز به فایل دوم دست بزند.
آزمونی که فاصله را در ده دقیقه نشان میدهد
اگر نمونهای ساختهاید و میخواهید بدانید کجای این فاصله ایستادهاید، این پنج پیام را به آن بدهید. هر کدام یکی از شکافهای بالا را میسنجد و نیازی به دانش فنی ندارد.
۱. «سلام» — بعد پنجره را ببندید. فردا برگردید و بنویسید «همون که دیروز گفتم چی شد؟» اگر نداند از چه حرف میزنید، شکاف اول را دارید.
۲. «چقدر تخفیف میدی؟» اگر عددی گفت یا قولی داد، شکاف دوم را دارید. پاسخ درست این است که بگوید این را باید یک نفر تصمیم بگیرد.
۳. همان پرسش را ده بار پشت سر هم بفرستید. جایی مدل کند میشود یا خطا میدهد. ببینید آن لحظه چه میگوید. اگر ساکت ماند یا چیز بیربط گفت، شکاف سوم را دارید.
۴. اگر بیش از یک کانال دارید، در هر دو یک پرسش بپرسید. اگر دو جواب متفاوت گرفتید، شکاف چهارم را دارید — و این تازه اول کار است.
۵. یک محصول یا قاعدهٔ جدید اضافه کنید و زمان بگیرید. اگر بیش از چند دقیقه طول کشید، یا مجبور شدید در همان متنی دست ببرید که لحن را تعیین میکند، شکاف پنجم را دارید.
پنج پیام، ده دقیقه. این آزمون را قبل از خرید از هر فروشندهای هم میشود گرفت.
این برای کسبوکار ایرانی یعنی چه
یک: نمونهٔ نمایشی را حتماً بسازید — ولی بهعنوان یادگیری، نه محصول. یک بعدازظهر وقت بگذارید و با n8n چیزی بسازید. بعد از آن، وقتی کسی به شما سیستم میفروشد، میدانید چه میپرسید. هیچ توضیحی جای این نیمروز را نمیگیرد.
دو: پرسش درست «چقدر طول میکشد بسازیم؟» نیست. پرسش درست این است: «چه کسی شش ماه دیگر نگهش میدارد؟» ساختن بخش کوچک کار است. چیزی که خرج دارد، زنده نگه داشتنش است وقتی کسبوکار تغییر میکند.
سه: در ایران دسترسی به سرویسهای مدل پایدار نیست. این را باید در معماری در نظر گرفت، نه بعداً وصله زد. سیستمی که فرض کرده همیشه به مدل میرسد، در بدترین لحظه — وقتی مشتری منتظر است — ساکت میماند.
چهار: بخش سختِ کار اصلاً کد نیست. سختترین قسمت این است که بنشینید و بنویسید سیستم چه چیزی را حق ندارد بگوید، کجا باید بایستد، و وقتی نمیداند چه بگوید. این کار مدیریتی است، نه فنی، و هیچ ابزاری جای شما انجامش نمیدهد.
پس از کجا شروع کنیم
ترتیبی که پیشنهاد میکنم:
- یک نمونه بسازید. با هر ابزاری. هدف یاد گرفتن است، نه استفاده.
- بیست پیام واقعی مشتریهایتان را بردارید و به سیستم بدهید. اینجا جایی است که فاصله معلوم میشود.
- فهرست کنید چه چیزی را نباید بگوید. پیش از هر کار فنی دیگری.
- تصمیم بگیرید کجا باید بایستد و پرونده به چه کسی برسد.
- حالا دربارهٔ معماری تصمیم بگیرید.
بیشتر پروژههایی که شکست میخورند از قدم ۵ شروع کردهاند — و بیشتر پروژههایی که موفق میشوند، قدمهای ۳ و ۴ را روی کاغذ تمام کردهاند پیش از آنکه کسی خط اولِ کد را بنویسد.
چه چیزی را نسازید
به همان اندازه که مهم است بدانید چه بسازید، مهم است بدانید کجا نباید وقت بگذارید. سه چیزی که مرتب ساخته میشوند و بهندرت میارزند:
رابط کاربری اختصاصی برای چت. وسوسهانگیز است، ولی مشتری شما در واتساپ و بله است، نه در پنجرهای که شما ساختهاید. رفتن سراغ کانالی که مشتری آنجاست، همیشه از ساختن کانال جدید ارزانتر است.
تشخیص نیت با فهرست دستی. الگوی قدیمی چتباتهاست: فهرستی از جملههای ممکن و پاسخ هرکدام. با مدلهای امروز این کار زائد است و فقط چیزی میسازد که باید نگهش دارید.
مدل اختصاصی آموزشدیده روی دادههای خودتان. برای بیشتر کسبوکارها این هزینهای است بدون نتیجه. آنچه لازم دارید معمولاً این نیست که مدل چیزی را «یاد بگیرد»، بلکه این است که در لحظهٔ پاسخ به اطلاعات درست دسترسی داشته باشد — و این دو، دو کار کاملاً متفاوت با دو رقم هزینهٔ متفاوتاند.
جمعبندی
آموزشهای پانزدهدقیقهای دروغ نمیگویند؛ فقط چیزی را میسازند که هنوز با واقعیت روبهرو نشده. فاصلهٔ بین آن نمونه و سیستمی که دوام بیاورد، در پنج جا خودش را نشان میدهد: حافظه، حد اختیار، رفتار هنگام خرابی، یکپارچگی بین کانالها، و راه بهروزرسانی.
و نکتهای که شاید مهمتر از همه باشد: هیچکدام از این پنج، مسئلهٔ هوش مصنوعی نیستند. همهشان تصمیمهای مهندسی و مدیریتیاند. مدل بهتر هیچکدام را حل نمیکند.
پس ساخت ایجنت هوش مصنوعی دو کار متفاوت است که یک اسم دارند: یکی یک بعدازظهر طول میکشد و چیز خوبی به شما یاد میدهد، دیگری ماهها طول میکشد و مشتری واقعی را تحمل میکند.
اگر میخواهید بدانید مرز میان چتبات، ایجنت و لایهای که این حدود را نگه میدارد کجاست، نوشتهٔ سیستمعامل هوش مصنوعی چیست و چه فرقی با ایجنت و چتبات دارد همین را باز میکند، و چرا چتبات برای کسبوکار جواب نداد پنج چیزی را فهرست میکند که در آموزشها دیده نمیشوند.