معماری سیستم جایگزین مدل‌های زبانی بزرگ در مدیریت داده‌های محلی

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

برای حل این مشکل، پروژه Hey Daejeon در ۴ اوت ۲۰۲۶ راه‌اندازی شد تا ثابت کند یک سیستم که عمیقاً روی یک شهر خاص (دجون در کره جنوبی) متمرکز است، از مدل‌های عمومی بسیار کارآمدتر است. هدف این پروژه طراحی سیستمی است که یک شهر خاص را به صورت عمیق درک کند. اکثر کاربران برای کارهای کلی به مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تکیه می‌کنند، اما این مدل‌ها در مواجهه با تغییرات لحظه‌ای اداری یا برنامه‌های حمایتی خاص هر محله ناتوان‌اند. این شکاف به این دلیل وجود دارد که داده‌های محلی به ندرت در یک پایگاه داده واحد و پاکیزه قرار دارند؛ بلکه معمولاً در اطلاعیه‌های سازمانی، مجموعه‌داده‌های عمومی و صفحات وب بی‌شماری محبوس شده‌اند که مدام تغییر می‌کنند.

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

• کدام برنامه‌های حمایتی محلی در حال حاضر پذیرش درخواست می‌کنند؟
• چه تغییرات اداری در یک محله خاص در حال رخ دادن است؟
• آخر هفته جاری کجا می‌توانم تفریح کنم یا به بازدید بروم؟
• کدام سازمان محلی می‌تواند در حل یک مشکل خاص به من کمک کند؟

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

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

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

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

• آیا این پرس‌وجوی خاص نیاز به جست‌وجوی وب دارد؟
• آیا سیستم باید از داده‌های محلی استفاده کند یا مستقیماً به سراغ LLM همه‌منظوره برود؟
• وقتی اطلاعات بازیابی‌شده کیفیت لازم را ندارند، چه اتفاقی می‌افتد؟
• چگونه می‌توان تشخیص داد که مسیریاب تصمیم اشتباه گرفته است؟
• آیا سیستم به اندازه کافی قابل اعتماد است که برای کاربران واقعی مستقر شود؟

در واقع، کاهش تصمیمات غلط مسیریاب، بسیار مهم‌تر از افزودن قابلیت‌های جدید به مدل بود. برای مدیریت این مسیرها، پروژه از ترکیبی از مسیریابی اکتشافی (Heuristic)، مسیریابی مبتنی بر LLM، حفاظ‌ها و ارزیابی‌های داخلی استفاده کرد. این رویکرد نشان‌دهنده یک تغییر جهت در توسعه هوش مصنوعی است: در اینجا «محصول» واقعی، معماری سیستم است، نه پارامترهای مدل زیربنایی.

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

پروژه Hey Daejeon یک محصول نهایی نیست، بلکه یک آزمایش تکاملی است که با چرخه تکرار شونده «یافتن مشکل $\rightarrow$ تشکیل فرضیه $\rightarrow$ ساخت $\rightarrow$ تست $\rightarrow$ شکست $\rightarrow$ بهبود» پیش می‌رود. این فرآیند به توسعه‌دهنده آموخت که مفیدترین درس‌ها اغلب از بخش‌هایی به دست می‌آیند که در اولین تلاش کار نکردند.

در حال حاضر محدودیت‌هایی وجود دارد، از جمله:

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

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

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

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

• معماری کلی سیستم و مکانیسم‌های مسیریابی پرس‌وجو.
• مقایسه مسیریابی اکتشافی (Heuristic) در مقابل مسیریابی مبتنی بر LLM.
• طراحی حفاظ‌ها (Guardrails) و تست‌های پیش از استقرار.
• روش‌های ارزیابی داخلی و بدهی‌های فنی (Technical Debt) مواجه شده در طول ساخت.

به جای نمایش صرف یک محصول تمام شده، هدف این پروژه مستند کردن تصمیمات، شکست‌ها و بهبودهایی است که به این سرویس شکل دادند. Hey Daejeon تلاشی است برای دیدن اینکه چه اتفاقی می‌افتد وقتی یک هوش مصنوعی طراحی شود تا یک شهر را واقعاً خوب بشناسد، به جای اینکه سعی کند تمام جهان را بفهمد.

گام بعدی شما

• اگر در حال ساخت ابزاری برای داده‌های تخصصی هستید، به جای Fine-tuning مدل، روی لایه مسیریابی (Routing) تمرکز کنید.
• برای کاهش توهمات، از ترکیب تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — با لایه‌های بررسی صحت (Guardrails) استفاده کنید.
• معیارهای ارزیابی سیستم خود را بر اساس «نرخ تصمیمات درست مسیریاب» تعریف کنید، نه فقط کیفیت پاسخ نهایی.

اما چالش‌های سخت‌افزاری برای اجرای این لایه‌های مسیریابی در مقیاس شهری چیست؟ در تحلیل ما درباره‌ی بهینه‌سازی استنتاج در لبه (Edge Inference) پاسخ را بیابید.