هزینه ساخت ایجنت هوش مصنوعی: ساختار مهم‌تر از تعداد سؤال

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

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

دو پول جدا: یک بار ساختن، هر ماه اجرا کردن

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

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

فرمول هزینه ساخت ایجنت هوش مصنوعی سه جزء دارد، نه دو جزء

حساب ذهنی رایج دو جزء دارد: تعداد سؤال ضرب در قیمت یک بار پرسیدن از مدل. حساب درست سه جزء دارد:

هزینه‌ی ماهانه = حجم ماهانه × تعداد فراخوانی مدل در هر بار × قیمت هر فراخوانی

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

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

فرض کن سه درخواست داری و هر فراخوانی، فرضا، ۱۵۰۰ تومان خرج دارد. اول: پیام‌های ورودی مشتری را به فروش، پشتیبانی یا شکایت دسته‌بندی کن؛ ماهی ۴۰۰۰ پیام. دوم: سؤال فنی مشتری را از روی کاتالوگ محصول جواب بده؛ ماهی ۱۲۰۰ سؤال. سوم: «سفارشم کجاست؟» که گاهی بررسی پرداخت می‌خواهد، گاهی انبار، گاهی هر دو؛ ماهی ۸۰۰ سؤال.

ردیف اول و سوم را کنار هم بگذار. با یک‌پنجم حجم، همان‌قدر خرج. اگر فقط حجم را نگاه کرده بودی، پیگیری سفارش ارزان‌ترین کار روی میز به نظر می‌رسید، در حالی که همان کاری بود که بیشترین فراخوانی را در هر بار داشت. و یک چیز دیگر هنوز در عدد ایجنت نیامده: وقتی یک ابزار خطا می‌دهد، مثلا انبار جواب نمی‌دهد، ایجنت دوباره تصمیم می‌گیرد و فراخوانی اضافه می‌خورد. پس روی هر تخمین ایجنتی دست‌کم یک‌پنجم حاشیه بگذار. شش میلیون با این حاشیه می‌شود ۷٬۲۰۰٬۰۰۰ تومان، و حالا ردیف سوم از ردیف اول هم گران‌تر است.

ارزان‌ترین صرفه‌جویی، ساده کردن مسیر است نه عوض کردن مدل

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

پیگیری سفارش را دوباره نگاه کن. اگر سؤال را اول دسته‌بندی کنی، پرداخت یا انبار یا هر دو، و بعد زنجیره‌ی آماده‌ی همان دسته را اجرا کنی، مسیر دوباره ثابت می‌شود. به این مسیریاب ساده «روتر» می‌گویند: فقط بین مسیرهایی که از قبل نوشته‌ای انتخاب می‌کند. یک فراخوانی برای دسته‌بندی و دو تا برای زنجیره، یعنی سه به‌جای پنج. ۸۰۰ ضرب در ۳ ضرب در ۱۵۰۰ می‌شود ۳٬۶۰۰٬۰۰۰ تومان به‌جای شش میلیون، و مهم‌تر از پول، قابل پیش‌بینی: هر بار می‌دانی سیستم چه راهی رفته و اگر خراب شد، کدام قدم خراب شده.

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

چرا هزینه‌ی هر گفتگو تندتر از تعداد قدم‌ها بالا می‌رود

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

یک دستیار پشتیبانی فرضی با ابزار جست‌وجو: دستور ثابتش ۸۰۰ توکن، پیام کاربر ۶۰، هر صدا زدن ابزار ۸۰، هر نتیجه‌ی ابزار ۴۰۰ و جواب آخر ۱۵۰ توکن. قیمت فرضی خواندن ۱۲۰ تومان برای هر هزار توکن و نوشتن ۴۸۰ تومان.

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

یک گفتگوی گیرکرده از هر صد، و قبضی که سه‌چهارم بالا می‌رود

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

دو سقف، و چرا هیچ‌کدام زیادی نیست

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

سقف دوم، سقف توکن هر گفتگو است، مثلا چهل هزار توکن. با نتیجه‌ی ابزار ۴۰۰ توکنی، کل مصرف هشت قدم حدود بیست و یک هزار توکن است؛ سقف قدم زودتر می‌رسد و سقف توکن بی‌کار به نظر می‌آید. حالا فرض کن ابزار به‌جای یک تکه، کل سند را برگرداند: ۲۰۰۰ توکن به‌جای ۴۰۰. ورودی هشت قدم به حدود ۶۵ هزار توکن می‌رسد و این بار سقف توکن حدود قدم ششم فعال می‌شود. ابزار خراب نشده بود؛ فقط جواب کامل‌تری داده بود. و همین ترتیب دو سقف را برعکس کرد. پس این دو تکراری نیستند و هرکدام حالتی را می‌گیرند که دیگری نمی‌بیند. یک نکته‌ی صادقانه هم: سقف علت را درست نمی‌کند. اگر گفتگوها مرتب به سقف می‌خورند، یعنی چیزی دستیار را در چرخه می‌اندازد، مثلا ابزاری که وقتی خطا می‌دهد نمی‌گوید حالا چه باید کرد. سقف جلوی ضرر را می‌گیرد؛ پیدا کردن علت هنوز کار توست.

برگه‌ای که پیش از قرارداد پر می‌کنی

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

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

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

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