ساخت ایجنت هوش مصنوعی: از سه درخواست، فقط یکی واقعا ایجنت می‌خواهد

سه درخواست روی میز یک برنامه‌نویس است و هر سه با همین جمله رسیده‌اند: «برای این یک ایجنت بساز.»

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

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

معیار ایجنت بودن، داشتن مدل زبانی نیست

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

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

اگر می‌توانی مسیر را روی کاغذ بکشی، زنجیره است. اگر نمی‌توانی، چون ادامه‌ی راه به جوابی بسته است که وسط کار به دست می‌آید، ایجنت است.

سه معماری، از ارزان به گران

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

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

آشپزی که در یخچال را باز می‌کند

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

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

حساب سه درخواست، یکی‌یکی

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

دسته‌بندی پیام‌ها

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

جواب از روی کاتالوگ

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

وضعیت سفارش

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

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

همان درخواست سوم، بدون ایجنت

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

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

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

دو دام هنگام انتخاب معماری

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

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

برای ساخت ایجنت هوش مصنوعی چقدر پایتون لازم است

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

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

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

یک ساعت با کاغذ، روی سه مسئله‌ی خودت

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

1. سه مسئله بنویس، هر کدام در یک جمله‌ی مشخص.
2. برای هر کدام مسیر را روی کاغذ بکش. اگر کشیده شد، زنجیره است.
3. معماری هر کدام را انتخاب کن و دلیلش را بنویس، نه فقط اسمش را.
4. حجم ماهانه را تخمین بزن.
5. خرج ماهانه را حساب کن: حجم، ضرب در تعداد فراخوانی در هر بار، ضرب در هزینه‌ی هر فراخوانی. این آخری را از قیمت‌نامه‌ی سرویسی بردار که واقعا استفاده می‌کنی، نه از عدد این نوشته.
6. برای موردی که ایجنت انتخاب کردی، یک بند بنویس: اگر زنجیره‌اش کنی چه چیزی از دست می‌رود؟

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

این حساب چه چیزی را نشان نمی‌دهد

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

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