وقتی میگوییم «ما چتبات نمیسازیم»، منکر ارزش گفتوگو نیستیم؛ بلکه باور داریم گفتوگو کلِ معماری نیست. پنجرهٔ چت صرفاً یک درگاه ورودی است؛ اما آنچه پشت این درگاه میگذرد، پایداری یا فروپاشی سامانهٔ شما را در دنیای واقعی تعیین میکند.
در مسیر توسعهٔ سامانههای عاملمحور، بارها با دو الگوی رایج مواجه شدیم؛ الگوهایی که در نگاه نخست جذاب بودند، اما در عمل هر دو را کنار گذاشتیم. بررسی چراییِ این تصمیم اهمیت زیادی دارد؛ چراکه دقیقاً همین «چرا»، مرز میان یک نمایش جذاب و یک سامانهٔ قابلاتکا را مشخص میکند.
الگوی اول: عاملهایی که با یکدیگر گفتوگو میکنند
الگوی نخست بسیار وسوسهانگیز است: چند عامل طراحی کنید، آنها را در یک اتاق گفتوگو مستقر سازید و اجازه دهید با تبادل نظر به پاسخ نهایی برسند. در این ساختار، یکی نقش برنامهریز را بر عهده میگیرد، دیگری منتقد میشود، آن یکی مجری، و کارها را در قالب یک رشتهگفتوگوی آزاد میان خود دستبهدست میکنند.
این رویکرد شاید در دموها بسیار جذاب جلوه کند، اما هنگام پیادهسازی در مقیاس بزرگ، با مشکلی ساختاری روبهرو میشود. وقتی هماهنگی صرفاً حاصل یک گفتوگوی آزاد باشد، عملاً هیچ عاملی مسئولیت نهایی را بر عهده نمیگیرد. خطاها در طول این زنجیره روی هم انباشته میشوند؛ تا جایی که یک کجفهمی کوچک در ابتدای مسیر، در پایان به خطایی بزرگ بدل میشود. از سوی دیگر، مبهم بودن مرز مسئولیتها باعث میشود که هنگام بروز خطا، ریشهیابی آن تقریباً ناممکن باشد. سامانهای که نتوان خطاهایش را ردیابی کرد، هرگز قابلاتکا نخواهد بود.
گفتوگوی میان عاملها هزینهٔ هماهنگی را از بین نمیبرد، بلکه صرفاً آن را پنهان میکند؛ و هزینههای پنهان همیشه خطرناکترین نوع هزینهها هستند.
الگوی دوم: یک عامل و انبوهی از ابزار
الگوی دوم از آن سوی بام میافتد: ساخت عاملی بسیار توانمند که به تمامی ابزارهای احتمالی مجهز شده است. در اینجا با یک مدل واحد و دهها ابزار روبهرو هستیم، با این امید که خودِ عامل تشخیص دهد چه زمانی باید به سراغ کدام ابزار برود.
این الگو در ظاهر سادهتر به نظر میرسد، اما شکنندگیهای خاص خود را دارد. هرچه ابزارهای بیشتری در اختیار یک عامل بگذاریم، تصمیمگیری برای او سختتر میشود و احتمال بروز خطا در کارش بالا میرود. عاملی که وظیفه دارد همزمان پشتیبان مشتری، تحلیلگر مالی و نویسنده باشد، در هیچیک از این زمینهها به تخصص واقعی نمیرسد. افزون بر این، وقتی تمام توانمندیها در کالبدی واحد فشرده شوند، دیگر نمیتوان بخشی مشخص را بهتنهایی ارزیابی کرد، بهبود داد یا محدود ساخت. وقتی همهچیز در هم تنیده باشد، مهار هیچ بخشی ممکن نیست.
این وضعیت درست مثل دانشآموز همهفنحریفی است که نمرههایش در هیچ آزمونی قابلاتکا نیست؛ نه به این دلیل که هوش کافی ندارد، بلکه چون مرزی برای وظایف خود تعریف نکرده است.
راه سوم: ساختار، نه گفتوگو
راهکاری که ما به آن رسیدیم، نه گفتوگوی آزاد میان عاملهاست و نه تکیه بر عاملی همهفنحریف؛ بلکه تعریف ساختاری منسجم است: نقشهایی مشخص با مرزهایی کاملاً روشن که بهجای تبادل پیامهای پراکنده، از طریق رویدادهای تعریفشده و قابلردیابی با یکدیگر هماهنگ میشوند.
در این دیدگاه، هر عامل صرفاً مسئولیت یک حوزهٔ مشخص را بر عهده دارد و بس. هماهنگی حاصلِ گفتوگویی تصادفی نیست، بلکه از جریان کاریِ شفافی سرچشمه میگیرد؛ درست مانند سازمانی کارآمد که در آن هر فرد وظیفهٔ خود را میشناسد و کارها با اسنادی مشخص از بخشی به بخش دیگر منتقل میشوند. با این روش، در صورت بروز مشکل، دقیقاً میدانید باید به سراغ کدام بخش بروید؛ برای بهبود عملکرد سامانه، مشخص است که کدام نقش را باید ارتقا دهید؛ و برای محدود ساختن یک عامل نیز مرزها از پیش تعریف شدهاند.
این تفاوت اگرچه ظریف است، اما نقشی تعیینکننده ایفا میکند. الگوی نخست مسئولیت را چنان در میان گفتوگوها حل میکند که عملاً ناپدید میشود. الگوی دوم مسئولیت را در ساختاری ذهنی و واحد فشرده میکند تا تفکیکناپذیر شود. اما راهکار سوم، مسئولیت را در جایگاهی شفاف قرار میدهد تا بهراحتی بتوان آن را دید، سنجید و به آن اعتماد کرد.
چرا این موضوع برای شما اهمیت دارد
اگر قرار است هوش مصنوعی مسئولیتی واقعی را در سازمان شما بر عهده بگیرد و فراتر از یک نمایش جذاب در دمو عمل کند، آنچه اهمیت دارد پنجرهٔ چت نیست؛ بلکه مسئله این است که هنگام مواجههٔ سامانه با شرایط عملیاتی سخت، آیا رفتار آن قابلردیابی است، آیا میتوان بخشهای مختلفش را بهطور مجزا بهبود داد، و آیا مرزهای عملکردی آن تضمینشدنی است یا خیر.
ما چتبات نمیسازیم؛ چراکه چتبات صرفاً یک لایهٔ ظاهری است و تمرکز ما روی ساختاری است که از این ظاهر پشتیبانی میکند. الگوی درست، آن نیست که در دموها درخشانتر جلوه کند، بلکه الگویی است که در روزهای سخت نیز پایدار و سرپا بماند.