درون معماری LangGraph؛ جداسازی منبع داده از استدلال برای فروش دقیق‌تر

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

به گزارش وب‌سایت dev.to، این سیستم با استفاده از OpenAI Realtime API، فراتر از یک چت‌بات ساده عمل کرده و مدل زبانی را صرفاً به عنوان یک موتور استدلال (Reasoning Engine) به کار می‌گیرد، نه به عنوان یک پایگاه داده. این معماری به هوش مصنوعی اجازه می‌دهد تا کل تراکنش را به‌طور خودمختار مدیریت کند، بدون اینکه قیمت‌ها یا اعداد موجودی را از خودش اختراع کند. این رویکرد یادآور تحولاتی است که در اتوماسیون اداری رخ داده و به‌کارگیری عامل‌های هوشمند برای پردازش خودکار فاکتورهای مالی را برای کسب‌وکارهای کوچک تسهیل کرده است.

در دنیای واقعی، اکثر سیستم‌های صوتی فعلی با تأخیر بالا و توهم (Hallucination) دست‌وپنجه نرم می‌کنند؛ جایی که مدل موجود بودن یک محصول را حدس می‌زند. برای یک کسب‌وکار، اعلام قیمت اشتباه یا تعداد موجودی جعلی یک شکست بحرانی است. این پروژه با ایجاد یک مرز سخت بین هوش مکالمه‌ای AI و منطق قطعی (Deterministic) کسب‌وکار، این مشکل را حل کرده است. اصل بر این است که هوش مصنوعی باید درباره داده‌های تجاری استدلال کند، نه اینکه آن‌ها را ابداع کند.

لایه صوت و هوش

در این سیستم، Twilio به عنوان درگاه تلفنی برای مدیریت تماس‌های ورودی استفاده می‌شود. جریان پایه تماس از یک مسیر مشخص پیروی می‌کند: خریدار تماس می‌گیرد $\rightarrow$ Twilio تماس را دریافت می‌کند $\rightarrow$ سیگنال صوتی به سیستم AI ارسال می‌شود $\rightarrow$ هوش مصنوعی مکالمه را پردازش می‌کند $\rightarrow$ پاسخ تولید می‌شود $\rightarrow$ خریدار پاسخ را می‌شنود.

برای اجتناب از تأخیرهای رایج در خط لوله‌های سنتی (تبدیل گفتار به متن $\rightarrow$ ارسال به LLM $\rightarrow$ تبدیل متن به گفتار)، توسعه‌دهنده از OpenAI Realtime API استفاده کرد. در ابتدا، یک خط لوله استاندارد در نظر گرفته شده بود، اما این روش باعث ایجاد تأخیرهای ۴ تا ۵ ثانیه‌ای برای هر پاسخ می‌شد. با استفاده از قابلیت‌های صوتی بلادرنگ، سیستم شبیه به یک گفتگوی طبیعی به نظر می‌رسد، نه یک چت‌بات که صرفاً میکروفونی به آن وصل شده است.

برای حفظ زمینه (Context)، عامل صوتی هر جمله را به عنوان یک پرس‌وجوی جدید نمی‌بیند، بلکه وضعیت جلسه (Session State) را ردیابی می‌کند. این وضعیت شامل هویت خریدار، مدل خاص محصول مورد بحث و مکان‌های ترجیحی انبار است. برای مثال، اگر خریدار بگوید «۵۰ عدد از آبی‌ها را می‌خواهم»، هوش مصنوعی به زمینه فعلی مکالمه مراجعه می‌کند:

• خریدار: توزیع‌کنندگان ABC
• محصول فعلی: محصول X
• گونه (Variant): آبی
• تعداد درخواستی: ۵۰
• ترجیحات خریدار: انبار ترجیحی (Pune)، زبان ترجیحی (انگلیسی)

این سازوکار مانع از آن می‌شود که هوش مصنوعی در طول یک تماس، سؤالات تکراری را بارها و بارها بپرسد.

ارکستراسیون از طریق LangGraph

قلب تپنده این سیستم LangGraph است که جریان کاری (Workflow) عامل را مدیریت می‌کند. به‌جای استفاده از یک پرامپت عظیم و واحد، عامل در حالت‌های (States) تعریف‌شده جابه‌جا می‌شود. این رویکرد مبتنی بر حالت، عیب‌یابی را بسیار ساده‌تر می‌کند؛ توسعه‌دهنده می‌تواند دقیقاً شناسایی کند که کدام مرحله شکست خورده است، به‌جای اینکه در مورد دلیل رفتار تصادفی AI فکر کند.

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

هوش مصنوعی به‌جای دسترسی مستقیم به پایگاه داده، از طریق ابزارهای (Tools) مشخصی با کسب‌وکار تعامل می‌کند:

• search_product(): یافتن کد کالا (SKU) صحیح.
• check_inventory(): تأیید سطح موجودی در لحظه. اگر خریدار ۱۰۰ واحد بخواهد اما فقط ۶۰ واحد موجود باشد، AI برنامه‌ریزی شده تا بگوید: «در حال حاضر ۶۰ واحد موجود است. آیا می‌خواهید سفارش را برای ۶۰ عدد ثبت کنم؟»
• get_dealer_price(): بازیابی قیمت‌های اختصاصی B2B.
• get_scheme(): بررسی طرح‌های قیمت‌گذاری قابل اعمال.
• get_customer_history(): دسترسی به داده‌های سفارشات قبلی.
• create_draft_order(): ارسال درخواست نهایی به بک‌اند.

ستون فقرات داده‌ها

پایداری سیستم با استفاده از PostgreSQL به عنوان تنها منبع حقیقت (Single Source of Truth) برای داده‌های دائمی تضمین شده است. توسعه‌دهنده به‌طور صریح دسترسی مستقیم LLM به SQL را ممنوع کرده تا از تغییرات غیرمجاز در داده‌ها یا پرس‌وجوهای نامنظم جلوگیری کند. در طراحی دامنه، از UUIDها برای کلیدهای اصلی استفاده شده و برچسب‌های زمانی (Timestamps)، کلیدهای خارجی، ایندکس‌ها و پشتیبانی از حذف نرم (Soft-delete) گنجانده شده است.

مدل‌های داده ساختاریافته

طرح (Schema) PostgreSQL به‌گونه‌ای سازماندهی شده است که هوش مصنوعی یک بنیاد پاک داشته باشد. داده‌ها به موجودیت‌های اصلی تقسیم شده‌اند:

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

Redis وظیفه مدیریت داده‌های «سریع» را بر عهده دارد. این ابزار وضعیت‌های موقت مکالمه، شناسه‌های جلسه (Session IDs) و لایه‌های کش را ذخیره می‌کند تا پاسخ‌های صوتی سریع باقی بمانند. مدل ذهنی این است: PostgreSQL = داده‌های تجاری دائمی؛ Redis = وضعیت موقت سریع + کش. این جداسازی تضمین می‌کند که در حالی که AI درباره داده‌ها استدلال می‌کند، محاسبات واقعی — مانند قیمت نهایی پس از تخفیف‌ها — در بک‌اند FastAPI انجام شود، نه در داخل LLM.

منطق قیمت‌گذاری اختصاصی خریدار

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

قیمت پایه محصول $\rightarrow$ قیمت اختصاصی خریدار $\rightarrow$ طرح قابل اعمال $\rightarrow$ تخفیف $\rightarrow$ قیمت نهایی.

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

یکپارچگی سازمانی و حافظه

مرحله نهایی خط لوله، یکپارچگی با ERP است. عامل AI هرگز ERP را به‌طور مستقیم تغییر نمی‌دهد. در عوض، یک مرز ایمنی را دنبال می‌کند: AI $\rightarrow$ ابزار $\rightarrow$ اعتبارسنجی بک‌اند $\rightarrow$ ERP. این کار مانع از آن می‌شود که ماهیت غیرقابل‌پیش‌بینی AI، سیستم‌های قطعی سازمانی را فاسد کند.

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

• انبارهای ترجیحی
• محصولات ترجیحی
• مقادیر معمول سفارش
• ترجیحات ارتباطی

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

پشته فنی (Technical Stack)

پیاده‌سازی کامل بر یک پشته مدرن AI متکی است که برای قابلیت اطمینان طراحی شده است:

• فرانت‌اند: Next.js با Tailwind CSS و shadcn/ui.
• بک‌اند: FastAPI با SQLAlchemy ORM و Alembic برای مهاجرت‌های دیتابیس.
• پایگاه‌داده: PostgreSQL به همراه pgvector برای جست‌وجوی معنایی.
• کش / وضعیت: Redis.
• صوت: Twilio.
• هوش مصنوعی بلادرنگ: OpenAI Realtime API.
• ارکستراسیون عامل: LangGraph.
• مانیتورینگ: Sentry و OpenTelemetry برای ردیابی شکست ابزارها و تأخیرها.
• کنترل نسخه: Git و GitHub.

چالش‌ها و تکرارهای آینده

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

• بازیابی مکالمه: مدیریت اصلاحات ظریف، مانند زمانی که کاربر می‌گوید «نه، آن یکی نه. آن یکی آبی دیگر».
• شکست ابزارها: اطمینان از اینکه AI در زمان قطع بودن یک سرویس (مانند موجودی)، به‌جای تظاهر به موفقیت، این موضوع را به‌درستی اعلام کند.
• امنیت: پیاده‌سازی حفاظت از اطلاعات شخصی (PII)، تأیید تماس، لاگ‌های حسابرسی و مجوزهای سخت‌گیرانه برای ابزارها.
• تأخیر: ادامه بهینه‌سازی خط لوله صوتی برای اطمینان از اینکه عامل شبیه به یک مکالمه انسانی است.

نرده‌های حفاظتی معماری (Guardrails)

یکی از حیاتی‌ترین درس‌های آموخته شده، خطر دسترسی مستقیم به پایگاه داده بود. توسعه‌دهنده بر یک «نه» قاطع به مسیر «LLM $\rightarrow$ Database» تأکید می‌کند. در عوض، سیستم مسیر اعتبارسنجی شده‌ی «LLM $\rightarrow$ Tool $\rightarrow$ Backend $\rightarrow$ Database» را تحمیل می‌کند.

این سازوکار خاص امکانات زیر را فراهم می‌کند:

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

مسیر رسیدن به تولید (Production)

پروژه در حال حاضر از یک نمونه اولیه به یک سیستم کاربردی تبدیل می‌شود. نقشه راه توسعه‌دهنده بر ساخت بنیادها پیش از افزودن ویژگی‌های «هوشمند» متمرکز است. لیست اولویت‌های فعلی عبارت است از:

• ساخت APIهای اصلی بک‌اند و خط لوله صوتی.
• اتصال عامل به ابزارهای تجاری و جریان کاری سفارش.
• پیاده‌سازی حافظه مشتری و اتصالات موجودی.
• طراحی لایه همگام‌سازی ERP.
• افزودن قابلیت مشاهده (Observability) و تست مکالمات دنیای واقعی.

هدف نهایی یک تجربه بدون درز است: تماس $\rightarrow$ گفتگو $\rightarrow$ تأیید $\rightarrow$ سفارش.

تأملات نهایی مهندسی

این پروژه دیدگاه توسعه‌دهنده را به مهندسی نرم‌افزار به‌طور بنیادی تغییر داده است. مدل سنتی «فرانت‌اند + بک‌اند + دیتابیس» به مجموعه‌ای از پرسش‌های پیچیده‌تر درباره «عامل بودن» (Agency) و «حقیقت» تبدیل شده است. ملاحظات کلیدی اکنون شامل موارد زیر است:

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

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

گام بعدی شما

• اگر در حال ساخت عامل‌های AI هستید، دسترسی مستقیم مدل به دیتابیس را حذف کرده و از لایه Tool-based استفاده کنید.
• برای کاهش تأخیر در سیستم‌های صوتی، به‌جای زنجیره STT $\rightarrow$ LLM $\rightarrow$ TTS، از APIهای Realtime استفاده کنید.
• منطق‌های محاسباتی حساس (مانند قیمت و مالیات) را هرگز به مدل زبانی نسپارید و آن‌ها را در کد بک‌اند پیاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.