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

تصور کنید یک ابزار حرفه‌ای مدیریت بحران و سیل را دارید که بدون هیچ سروری، تنها در یک تب مرورگر اجرا می‌شود. پروژه Don Watch دقیقاً همین هدف را دنبال می‌کند و یک دوقلوی دیجیتال (Digital Twin) از رودخانه دان در شفیلد را مستقیماً روی واحد پردازش گرافیکی (GPU) کاربر میزبان می‌کند. این پروژه در واقع پاسخی به یک پرسش بنیادین است: چه مقدار از قابلیت‌های یک ابزار جدی مدیریت بحران را می‌توان در مرورگر جای داد تا همچنان شبیه به یک ابزار کاربردی باشد و نه یک دموی ساده؟

بسیاری از ابزارهای امروزی که ادعای «قدرت گرفته از هوش مصنوعی» دارند، تنها رابط‌های ساده‌ای برای فراخوانی APIهای ابری هستند. اما این پروژه مدل را کاملاً تغییر داده و کل پشته‌ی محاسباتی — از رندرینگ سه‌بعدی تا استنتاج (Inference) — که شبیه به لحظه‌ی آشپزی واقعی است و نه دوره‌ی آموزش آشپز، را به سخت‌افزار کاربر منتقل کرده است. طبق گزارش توسعه‌دهندگان، این چرخش تضمین می‌کند که ابزارهای حیاتی ایمنی، حتی در دفاتر میدانی بدون سیگنال یا روی لپ‌تاپ‌های محدود، فعال بمانند.

زمینه و شبیه‌سازی

در بخش شبیه‌سازی، این ابزار دره دان را با استفاده از داده‌های ارتفاعی LIDAR بازسازی کرده و مسیر واقعی رودخانه را روی آن می‌اندازد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی رایانش لبه اشاره کردیم، انتقال پردازش به نزدیکی کاربر، تأخیر را به شدت کاهش می‌دهد. کاربران می‌توانند سیل نوامبر ۲۰۱۹ شفیلد را ساعت به ساعت و بر اساس سوابق رسمی آژانس محیط زیست (EA) بازپخش کنند. همان‌طور که کاربر خط زمانی را جابه‌جا می‌کند، سطح آب دقیقاً تا همان سطحی که در آن زمان ثبت شده است، بالا می‌رود. در حالت زنده نیز، شبیه‌ساز داده‌های جاری EA را دریافت کرده و سطح آب به‌روز می‌کند.

این سامانه برای رندر کردن زمین و آب از WebGPU و three.js استفاده می‌کند. برخلاف جلوه‌های بصری ساده، آب در اینجا یک سطح وابسته به سطح است که ارتفاعات واقعی سنجشگرها را دنبال می‌کند. این رویکرد با پیشرفت‌های اخیر در زیرساخت‌های وب همسو است؛ برای مثال، معرفی کرنل‌های جدید Hugging Face برای WebGPU گام مهمی در جهت افزایش سرعت اجرای مدل‌های پیچیده در مرورگرها بوده است. یک الگوریتم پر کردن «عرض-اول» (Breadth-first fill) تضمین می‌کند که آب تنها از طریق نقاط اتصال واقعی رودخانه و زمین‌های غرق‌شده پخش شود تا از پر شدن غیرواقعی گودال‌های دور از رودخانه جلوگیری شود. این میدان ارتفاعی (Height field) در یک بافت (Texture) نوشته می‌شود که سپس توسط شیدر (Shader) برای تعیین عمق و جابه‌جایی نمونه‌برداری می‌شود.

جزئیات فنی

جزئیات فنی این پیاده‌سازی به شرح زیر است:

• پشته رندرینگ: استفاده از three.js با WebGPURenderer. مدیریت سایه‌زنی به جای استفاده از رشته‌های دست‌نویس GLSL، از طریق TSL (زبان سایه‌زنی نود-محور Three.js) انجام می‌شود.
• اصلاحات هندسی: برای رفع تداخل بصری یا همان z-fighting در خط ساحلی، جایی که آب و زمین در هم نفوذ می‌کنند، سطح آب چند متر بالا برده شده است. این تغییر در فاصله دوربین نامرئی است اما باعث می‌شود آب تمیزتر روی زمین قرار گیرد.
• هوش مصنوعی روی دستگاه: یک مدل زبانی کوچک (SLM) — شبیه به پزشک عمومی که روی یک تخصص خاص آموزش دیده — در بازه ۱ تا ۲ میلیارد پارامتر از طریق WebLLM بارگذاری می‌شود. این مدل بدون نیاز به سرور، بدون کلید API و بدون خروج هیچ داده‌ای از دستگاه، مستقیماً روی GPU کاربر اجرا می‌شود. همچنین یک سیستم جایگزین (Fallback) اسکریپتی برای دستگاه‌هایی که قادر به اجرای WebLLM نیستند تعبیه شده است.
• منابع داده: دریافت فیدهای بلادرنگ از Environment Agency (داده‌های سنجشگر و بارش)، نقشه‌های OpenStreetMap (برای شناسایی نقاط شاخص و نام مکان‌ها) و API نظارت بر سیل EA برای دسترسی به حسگرهای زنده و مناطق هشدار رسمی.
• قابلیت آفلاین: ساختار ابزار بر پایه خروجی استاتیک Next.js و اپلیکیشن وب پیشرونده (PWA) است. یک Service Worker پوسته و داده‌ها را کش می‌کند، در حالی که مدل زبانی در حافظه OPFS ذخیره می‌شود.

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

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

توسعه این پروژه نشان داد که شبکه‌های حسگر واقعی پراکنده هستند؛ برای مثال در مرکز شفیلد به جای یک شبکه متراکم، تنها تعداد محدودی سنجشگر وجود دارد. همچنین، اجرای هم‌زمان WebGPU و یک مدل محلی در یک تب، باعث رقابت شدید بر سر منابع GPU می‌شود؛ به همین دلیل توسعه‌دهنده مجبور شد تولید متن را به‌گونه‌ای زمان‌بندی (Bracket) کند تا حلقه رندرینگ بتواند منابع را آزاد کرده و وقفه ایجاد نشود. این چالش مدیریت منابع در محیط‌های محدود، یادآور سازوکارهای کنترل بار در BullMQ است که برای جلوگیری از اتمام حافظه VRAM در پردازش‌های سنگین هوش مصنوعی به کار می‌رود.

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

گام بعدی شما

• برای مشاهده نحوه مدیریت جابه‌جایی‌های بلادرنگ توسط WebGPU، نسخه عملیاتی را در آدرس donwatch.fortitude-omnis.group بررسی کنید.
• اگر توسعه‌دهنده هستید، مستندات WebLLM را برای اجرای مدل‌های محلی در مرورگر مطالعه کنید.
• بررسی کنید که آیا داده‌های LIDAR منطقه خودتان برای ساخت دوقلوهای دیجیتال مشابه در دسترس است یا خیر.

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