تصور کنید یک دستیار هوشمند با لحنی بسیار متقاعدکننده، داده‌های قدیمی را به شما می‌دهد یا به اشتباه وارد حساب کاربری شخص دیگری می‌شود؛ در محیط عملیاتی، این یک شکست محصول است، نه یک خطای کوچک. این تنش بنیادین، چالش اصلی توسعه‌دهندگان در ۱۴ اکتبر ۲۰۲۶ است: تفکیک دقیق میان سیستم‌های تعاملی و قابلیت‌های تولید محتوا.
همان‌طور که در تحلیل قبلی ما درباره‌ی تبدیل نویزهای تصادفی به داده‌های ساختاریافته در مدل‌های مولد اشاره کردیم، صنعت اکنون از بنچمارک‌های ساده‌ی مدل‌ها به سمت معماری‌های پیچیده سیستم حرکت می‌کند. این تغییر رویکرد بخشی از تحولات گسترده‌تر مهندسی در سال ۲۰۲۶ است که نحوه توسعه نرم‌افزار را بازتعریف می‌کند. چالش دیگر تنها هوشمندی مدل نیست، بلکه نحوه مدیریت این هوش در دل یک فرآیند تجاری است.
تفکیک بنیادین
هوش مصنوعی محاوره‌ای (Conversational AI) — شبیه به یک میزبان راهنما در هتل که شما را از یک نقطه به نقطه دیگر هدایت می‌کند تا کارتان راه بیفتد — بر اساس راهنمای فنی dev.to، توصیف‌کننده‌ی نحوه تعامل سیستم با انسان از طریق گفتگو است. هدف اصلی آن مدیریت جریان مکالمه و کمک به کاربر برای تکمیل یک وظیفه مشخص است.
در مقابل، هوش مصنوعی زاینده (Generative AI) — مثل نویسنده‌ای که بر اساس الگوهای آموزی، متنی کاملاً جدید خلق می‌کند — بر نحوه تولید متن، کد، تصویر یا صدا از الگوهای آموخته‌شده و زمینه (Context) متمرکز است. هدف آن تولید، تبدیل، خلاصه‌سازی، طبقه‌بندی یا استدلال روی محتواست.
این دو مفهوم مترادف نیستند. یک منوی تلفنی مبتنی بر قوانین، محاوره‌ای است اما زاینده نیست. مدلی که توصیف محصول می‌نویسد، زاینده است اما فاقد مدیریت وضعیت گفتگو، نوبت‌گیری (Turn-taking) یا مسیریابی قصد کاربر است. طبق گزارش Google Cloud، پلتفرم‌های فعلی برای پوشش نقاط تماس مشتری، هر دو حالت گفتگوی قطعی (Deterministic) و عامل‌های زاینده را پشتیبانی می‌کنند.
ابعاد معماری
این دو سیستم از الگوهای کنترلی و نیازهای داده‌ای کاملاً متفاوتی پیروی می‌کنند. هوش مصنوعی محاوره‌ای بر قوانین، گراف‌های گفتگو و مسیریابی قصد (Intent Routing) تکیه دارد تا کاربر به نتیجه‌ای مشخص برسد. این سیستم عبارات (Utterances)، قصدها، موجودیت‌ها، رونوشت‌ها و رویدادهای کانال را پردازش می‌کند. وضعیت اصلی آن شامل تاریخچه گفتگو، هویت کاربر، قصد، مقادیر اسلات (Slot values) و وضعیت گردش کار است.
اما هوش مصنوعی زاینده بر دستورالعمل‌ها، مبنی‌سازی (Grounding) و تولید محدودشده متکی است. این سیستم از مجموعه‌های پیش‌آموزش‌دیده بزرگ به همراه پرامپت‌ها، مثال‌ها، دانش سازمانی و بازخوردها استفاده می‌کند. وضعیت اصلی آن شامل پرامپت، زمینه بازیابی‌شده، وضعیت مدل، ابزارها، حافظه و طرح خروجی (Output Schema) است.
در حالی که اولی بر تکمیل وظیفه، مهار (Containment)، نرخ انتقال و رضایت مشتری (CSAT) تمرکز دارد، دومی با معیارهایی مثل پشتیبانی واقعی (Factual Support)، مرتبط بودن، کامل بودن، ایمنی، تأخیر (Latency) و هزینه توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — سنجیده می‌شود.
الگوی تولید ترکیبی
بسیاری از دستیاران تجاری مدرن برای دوری از نقاط ضعف هر یک از این دو رویکرد، از یک طراحی ترکیبی استفاده می‌کنند. در این مدل، یک لایه محاوره‌ای مدیریت هویت و وضعیت را بر عهده دارد، در حالی که یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — زبان را تفسیر کرده یا پاسخ را پیش‌نویس می‌کند.
در این ساختار، تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — پایگاه دانش تأییدشده را فراهم می‌کند. سیستم منابع معتبر را ایندکس کرده، بخش‌های مرتبط را بازیابی می‌کند و آن‌ها را همراه با درخواست کاربر به مدل می‌دهد. این کار باعث به‌روز بودن و قابل ردیابی بودن پاسخ‌ها می‌شود، هرچند بازیابی باید قوانین چرخه حیات سند و مجوزهای کاربر را رعایت کند.
در نهایت، سرویس‌های کاربردی معمولی، اقدامات مجاز مانند پردازش استرداد وجه یا به‌روزرسانی پایگاه داده را اجرا می‌کنند. این معماری تضمین می‌کند که مدل تنها زبان و قضاوت‌های احتمالی را مدیریت کند، در حالی که سرویس‌های محصول، هویت، سیاست‌ها و تراکنش‌ها را تحمیل می‌کنند.
مدیریت وضعیت و حافظه
وضعیت محاوره‌ای داده‌های کاربردی را دنبال می‌کند: چه کسی صحبت می‌کند، چه اطلاعاتی قبلاً ارائه شده، کدام مرحله از گردش کار فعال است و آیا جلسه (Session) می‌تواند از سر گرفته شود یا خیر.
اما زمینه در سیستم زاینده گسترده‌تر است و شامل نوبت‌های اخیر گفتگو، رکوردهای بازیابی‌شده، نتایج ابزارها، ترجیحات کاربر و خلاصه‌ها می‌شود. راهنمای فنی هشدار می‌دهد که حافظه دائمی تنها زمانی باید اضافه شود که دلیل واضح، قانون نگهداری مشخص و کنترل کاربر وجود داشته باشد.
ریسک‌های اقدام و یکپارچگی
هر دو سیستم از APIها استفاده می‌کنند، اما فرآیند انتخاب متفاوت است. یک گردش کار قطعی، پس از اعتبارسنجی فیلدهای مورد نیاز، یک API ثابت را فراخوانی می‌کند. اما یک عامل (Agent) ابزاری را از میان مجموعه‌ای از توابع موجود انتخاب می‌کند.
این استقلال عامل‌ها ریسک‌های امنیتی بزرگی ایجاد می‌کند. عامل‌ها به موارد زیر نیاز دارند:
- توابعی با دامنه محدود (Narrowly scoped)
- اعتبارنامه‌هایی با کمترین سطح دسترسی (Least-privilege)
- اعتبارسنجی سخت‌گیرانه پارامترها
- تأیید صریح برای اقدامات با تأثیر بالا
- مجوزهای کامل در سیستم‌های پایین‌دستی
تضمین کیفیت و تست
تست یک سیستم ترکیبی نیازمند دو رویکرد مجزا است. جریان‌های گفتگو از طریق مسیرها، قصدها، موجودیت‌ها، موارد خاص (Edge Cases) و پاسخ‌های یکپارچه تست می‌شوند، اما رفتار زاینده نیازمند گفتگوهای نماینده و خروجی‌های درجه‌بندی شده است.
توسعه‌دهندگان باید کل مسیر را تست کنند. یک تست موفق باید هویت کاربر، شواهد بازیابی‌شده، فراخوانی ابزار و نتیجه نهایی تجاری را حفظ کند تا در صورت شکست، بتوان علت را تشخیص داد، نه اینکه فقط شاهد خطا باشند.
برای تست یک دستیار ترکیبی، تیم‌ها باید:
- فهرستی از وظایف با نتایج مورد انتظار و قوانین ارجاع ایجاد کنند.
- گفتگوهای آزمایشی برای درخواست‌های عادی، مبهم، غیرپشتیبانی‌شده، ناامن، متخاصم (Adversarial) و خارج از محدوده بسازند.
- تست‌ها را با چندین عبارت و تاریخچه مختلف اجرا کنند تا از «شواهد ضعیف» ناشی از یک عبارت موفق اجتناب کنند.
- شکست‌های ناشی از وابستگی‌ها، دانش قدیمی و جلسات قطع‌شده را بررسی کنند.
- شکست‌های محیط عملیاتی را بر اساس علت بررسی کرده و پیش از تغییر پرامپت‌ها یا مدل‌ها، آن‌ها را به مجموعه رگرسیون اضافه کنند.
شکست‌های رایج در طراحی
به گزارش CodeGeeks، برخی از رایج‌ترین اشتباهات در پیاده‌سازی AI عبارتند از:
- استفاده از LLM برای جریان‌های فرم ثابت که اعتبارسنجی قطعی در آن‌ها ارزان‌تر و شفاف‌تر است.
- برخورد با تاریخچه گفتگوها به عنوان حافظه نامحدود بدون رعایت قوانین دسترسی.
- تکیه بر مدل برای پنهان کردن محتوای غیرمجاز که از طریق یک حساب سرویس مشترک بازیابی شده است.
- سنجش لحن پاسخ در حالی که تکمیل شدن وظیفه یا کیفیت ارجاع به اپراتور انسانی نادیده گرفته شده است.
- ارسال کاربران به اپراتورهای انسانی بدون ارائه زمینه، شواهد و اقداماتی که قبلاً توسط AI تلاش شده است.
امنیت و حاکمیت
کنترل‌های سنتی مثل محدود کردن نرخ درخواست (Rate Limiting)، احراز هویت و مدیریت جلسه همچنان ضروری هستند. با این حال، سیستم‌های زاینده ریسک‌های جدیدی را اضافه می‌کنند که در لیست OWASP ۲۰۲۵ آمده است؛ مواردی مثل تزریق پرامپت (Prompt Injection)، افشای اطلاعات حساس، مدیریت نادرست خروجی، agency بیش از حد، نقاط ضعف برداری (Vector) و جاسازی (Embedding)، و انتشار اطلاعات غلط یا مصرف نامحدود منابع.
در این راستا، مؤسسه NIST دسته‌بندی‌های عملیاتی دقیقی را برای مهار این مخاطرات و حاکمیت بر هوش مصنوعی تولیدی ارائه کرده است تا سازمان‌ها بتوانند ریسک‌ها را به صورت سیستماتیک مدیریت کنند. دستورات پرامپت نمی‌توانند مجوزهای دسترسی را تحمیل کنند. اگر مدلی یک CRM را فراخوانی می‌کند، خودِ CRM باید مجوزهای کاربر برای آن رکورد خاص را تأیید کند. اگر مدل پیش‌نویس استرداد وجه را می‌نویسد، کد باید محدودیت‌های سیاست را تحمیل کرده و تأییدیه بگیرد. پروفایل NIST برای هوش مصنوعی زاینده توصیه می‌کند این ریسک‌ها در تمام چرخه طراحی، توسعه، استفاده و ارزیابی مدیریت شوند.
کاربرد عملی: جستجوی خانه
در یک مثال واقعی، CodeGeeks اپلیکیشنی برای خریداران خانه ساخت که از صوت پشتیبانی می‌کند. این اپلیکیشن از مدل محاوره‌ای برای تعامل و از هوش مصنوعی زاینده برای توضیح تحلیل‌های بازار و ارائه توصیه‌های شخصی‌سازی‌شده استفاده می‌کند.
با این حال، داده‌های واقعی املاک و منطق محصول، توصیه‌ها را محدود می‌کنند. سیستم باید وضعیت را در طول گفتگو حفظ کند؛ مثلاً درخواست «مسافت کوتاه‌تر تا محل کار» به مکان و بودجه‌ای بستگی دارد که در نوبت‌های قبلی تعیین شده است. برای حفظ طبیعی بودن گفتگو، دستیار باید تأخیر صوتی را کم نگه دارد، در صورت ابهام در ترجیحات کاربر سؤال بپرسد و از اختراع حقایق درباره لیست املاک اجتناب کند.
زمان انتخاب هر رویکرد
| نیاز | نقطه شروع توصیه شده | دلیل |
|---|---|---|
| جمع‌آوری فیلدهای مورد نیاز و ثبت تراکنش ثابت | گردش کار محاوره‌ای قطعی | مراحل و قوانین اعتبارسنجی مهم‌تر از زبان باز هستند |
| پاسخ به سؤالات گسترده از دانش متغیر شرکت | هوش مصنوعی زاینده با RAG آگاه از مجوزها | کاربران به ترکیب اطلاعات از منابع تأییدشده و به‌روز نیاز دارند |
| مسیریابی درخواست‌ها به تیم درست | مدل قصد یا طبقه‌بند LLM با قوانین | طبقه‌بندی می‌تواند احتمالی باشد اما سیاست مسیریابی باید قطعی بماند |
| کمک به کاربر در کشف محصول مناسب | هوش مصنوعی محاوره‌ای ترکیبی | گفتگو ترجیحات را جمع‌آوری می‌کند، زبان زاینده توضیح می‌دهد و سرویس‌های کاتالوگ قیمت/موجودی را تحمیل می‌کنند |
| ایجاد پیش‌نویس، خلاصه یا کد | قابلیت هوش مصنوعی زاینده | ارزش اصلی در تولید محتواست نه مدیریت گفتگو |
| تکمیل کارهای چندمرحله‌ای در سیستم‌های مختلف | عامل تحت نظارت یا گردش کار ترکیبی | نیاز به ابزارها، وضعیت، مجوزها، تأییدیه‌ها و قابلیت بازیابی دارد |
دیدگاه CodeGeeks
ما هوش مصنوعی محاوره‌ای را به عنوان یک سطح کامل از محصول می‌بینیم. سیستم باید شخص را شناسایی کند، زمینه را مدیریت نماید، اطلاعات قابل اعتماد را بازیابی کند، از یکپارچگی‌ها به‌صورت ایمن استفاده کند و از عدم قطعیت‌ها بازیابی شود.
مدل‌های زاینده تعامل را بهبود می‌بخشند، اما جایگزین معماری، تضمین کیفیت (QA)، امنیت یا مالکیت محصول نمی‌شوند. تیم‌های تحویل ما، مهندسی AI و داده را با طراحی محصول، توسعه بک‌اند/فرانت‌اند و امنیت ابری ترکیب می‌کنند. این به ما اجازه می‌دهد با یک دستیار محدود شروع کنیم، کنترل‌های آن را اثبات کنیم و سپس دانش، کانال‌ها و اتوماسیون را بدون بازسازی بنیادها گسترش دهیم.
گام بعدی شما
- اگر از LLM برای فرم‌های ثبت اطلاعات استفاده می‌کنید، آن را با اعتبارسنجی‌های قطعی جایگزین کنید تا هزینه و نرخ خطا کاهش یابد.
- لایه مجوزهای دسترسی (Authorization) را از لایه مدل جدا کنید و آن را در سطح API یا پایگاه داده پیاده‌سازی کنید.
- یک مجموعه تست رگرسیون از شکست‌های واقعی محیط عملیاتی بسازید تا هر تغییر در پرامپت، باعث تخریب قابلیت‌های قبلی نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو