تصور کنید می‌خواهید هزینه‌های روزانه خود را ثبت کنید، اما باید هر بار یک اپلیکیشن سنگین را باز کرده و فرم‌های خسته‌کننده‌ای را پر کنید؛ دقیقاً به همین دلیل است که اکثر ما اپلیکیشن‌های مدیریت مالی را پس از چند روز رها می‌کنیم. یک الگوی رایج وجود دارد: کاربر اپلیکیشن را دانلود می‌کند، سه روز هزینه‌ها را وارد می‌کند، سپس آن را فراموش کرده و دو هفته بعد اپلیکیشن را حذف می‌کند.
سیستم DIA برای حل این مشکل، ثبت هزینه‌ها را به یک چت ساده در تلگرام، واتس‌اپ و دیسکورد تبدیل کرده است. طبق اعلام تیم توسعه، این سرویس در ۱۵ ژوئیه ۲۰۲۶ راه‌اندازی شد تا اصلاً نیازی به جابه‌جایی بین اپلیکیشن‌ها نباشد و کاربر فقط با ارسال پیامی مثل «۴۵۰ تومن ناهار»، تمام کارهای اداری بودجه‌بندی‌اش را انجام دهد. در این حالت، ربات هزینه را ثبت، دسته‌بندی، بودجه را به‌روزرسانی و اهداف پس‌انداز کاربر را تنظیم می‌کند.
این رویکرد دقیقاً همان فلسفهٔ کاربردی است که در پوشش پیشین ما از PIA Coach دیدیم؛ جایی که تمرکز به‌جای ابزارهای پیچیده، روی یادگیری الگوهای رفتاری برای بهره‌وری و مقابله با اهمال‌کاری بود و هدف نهایی، حذف اصطکاک کاربر است.
معماری سیستم
بر اساس مستندات فنی منتشرشده در dev.to، هستهٔ این سیستم بر پایه یک کلاس انتزاعی به نام BotBase و آداپتورها (لایه سازگارساز/Adapter) برای هر پلتفرم بنا شده است. این طراحی اجازه می‌دهد پیام‌های مختلف از محیط‌های متنوع، ابتدا به یک فرمت واحد در یک خط لوله (Pipeline) تبدیل شوند و سپس پاسخ فرمت‌شده بازگردانده شود. این ساختار در واقع تلاشی برای استانداردسازی تعاملات است، مشابه آنچه در تحلیل معماری MCP و تغییر نحوه تعامل مدل‌ها با ابزارها بررسی کردیم تا محدودیت‌های رابط‌های سنتی برطرف شود.
- کلاس BotBase: متدهای ضروری برای ارسال، دریافت و مدیریت دستورات را برای تمام ربات‌ها تعریف می‌کند.
- BotRegistry: مدیریت تمام ربات‌های فعال را بر عهده دارد. این بخش ربات‌های پیکربندی‌شده را در زمان شروع برنامه نمونه‌سازی (Instantiate) می‌کند و هنگام توقف اپلیکیشن، خروج منظم (Graceful Shutdown) را تضمین می‌کند.
- آداپتورهای پلتفرم: ابتدا تلگرام پیاده‌سازی شد و سپس واتس‌اپ و دیسکورد اضافه شدند. این اضافه شدن‌ها تنها نیازمند کدهای مختص هر پلتفرم بود، بدون اینکه منطق اصلی کسب‌وکار (Business Logic) تغییر کند.
برای مدیریت کاربران در محیط‌های مختلف، این لایهٔ سازگارساز شناسه‌های متنوع (مثل آی‌دی‌های چت تلگرام، شماره تلفن‌های واتس‌اپ و شناسه‌های دیسکورد) را به یک حساب داخلی واحد متصل می‌کند. وقتی پیامی می‌رسد، آداپتور بررسی می‌کند که آیا کاربر داخلی متصل‌شده‌ای وجود دارد یا خیر؛ اگر وجود نداشته باشد، کاربر را به مرحلهٔ احراز هویت هدایت کرده یا یک کاربر جدید می‌سازد.
مکانیسم پردازش و جزئیات فنی
برای اینکه هزینه‌های عملیاتی پایدار بماند، DIA از یک پردازشگر سه‌لایه استفاده می‌کند تا زبان طبیعی کاربر (مثلاً «۴۵۰ تومن ناهار در فودکورت دادم») را به داده‌های ساختاریافته شامل مبلغ، دسته‌بندی (مثلاً غذا) و یادداشت تبدیل کند. در این ساختار، مدل زبانی بزرگ (LLM) تنها به عنوان آخرین راهکار استفاده می‌شود.
- الگوهای Regex: عبارت‌های منظم (مثل «X هزینه برای Y») حدود ۷۰٪ از تمام پیام‌های دنیای واقعی را پردازش می‌کنند.
- تطبیق کلیدواژه‌ها: کلمات کلیدی دسته‌بندی‌ها را شناسایی کرده و ۲۰٪ دیگر ورودی‌ها را پوشش می‌دهند.
- پشتیبان LLM: مدل DeepSeek تنها برای ۱۰٪ پیام‌های پیچیده یا مبهم که توسط دو لایه اول شناسایی نشده‌اند، به کار گرفته می‌شود.
این استراتژی باعث می‌شود استنتاج (Inference) مدل‌های گران‌قیمت فقط در موارد ضروری رخ دهد. همچنین سیستم برای راحتی کاربر، اعداد کوتاه شده (Shorthand) را می‌فهمد؛ برای مثال، «3M» به سه میلیون، «300k» به سیصد هزار و «15m» به پانزده میلیون تبدیل می‌شود.
از نظر تجاری، این ربات یک سیستم پرداخت دوگانه دارد. اشتراک‌های استاندارد از طریق سرویس Paddle مدیریت می‌شوند و کاربران کریپتو-نیتیو می‌توانند با استفاده از USDC روی بلاک‌چین Solana پرداخت کنند. یکپارچگی با سولانا با بهره‌گیری از ابزارهای توسعه‌ای قدرتمند صورت گرفته است؛ به‌طوری که ربات می‌تواند یک آدرس کیف پول تولید کند و تراکنش را به‌صورت on-chain تأیید نماید و سپس اشتراک را فعال کند.
برای کاربر نهایی، این به معنای انتقال بدون درز بین پلتفرم‌هاست؛ مثلاً ثبت هزینه ناهار در تلگرام در طول روز و بررسی خلاصه ماهانه در دیسکورد در هنگام عصر، بدون هیچ‌گونه از دست رفتن داده‌ای. کل این پروژه روی یک سرور واحد FastAPI با پایگاه‌داده PostgreSQL و یک فرانت‌اند تحلیلی مینیمال اجرا می‌شود.
این معماری ثابت می‌کند که مدل‌های زبانی (LLM) زمانی بیشترین اثرگذاری را دارند که به جای موتور اصلی استخراج داده، به عنوان یک «تور نجات» (Safety Net) عمل کنند. با انتقال اکثریت وظایف به Regex و کلیدواژه‌ها، توسعه‌دهندگان می‌توانند عوامل هوش مصنوعی (AI Agents) را بدون افزایش خطی هزینه‌های API مقیاس‌بندی کنند.
اگر در حال ساخت یک عامل چت‌محور هستید، الگوهای ورودی خود را بررسی کنید تا ببینید آیا یک لایه Regex می‌تواند ۵۰٪ از فراخوانی‌های مدل شما را جایگزین کند یا خیر. هدف این است که فارغ از اینکه از DeepSeek یا مدل‌های دیگر استفاده می‌کنید، میزان «هوش» مورد نیاز برای کارهای روتین را به حداقل برسانید.
گام بعدی شما
- تحلیل الگوهای تکراری ورودی کاربران برای شناسایی کاندیداهای جایگزینی با Regex
- بررسی مدل‌های کوچک‌تر (SLM) برای لایه دوم پردازش به‌جای کلیدواژه‌های ساده
- تست پرداخت‌های درون‌برنامه‌ای با استانداردهای Web3 برای کاهش کارمزدهای تراکنش
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو