تصور کنید ابزاری بسازید که ادعا میکند هزینههای شما را ۶۸٪ کاهش میدهد، اما دو روز پیش از عرضه بفهمید این عدد هیچ پایه علمی ندارد و آن را پاک کنید. این دقیقاً اتفاقی است که برای vystartasv، سازنده ORA، درست پیش از انتشار نسخه v0.1.0 رخ داد. علیرغم حذف جسورانهترین ادعای عملکردی پروژه، این ابزار همچنان یک باینری قدرتمند به زبان Go است که میتواند وظایف پیچیده هوش مصنوعی را به زیر-وظایف قابل تأیید تجزیه کرده و آنها را به مقرونبهصرفهترین لایه مدلها هدایت کند.
امروزه اکثر ابزارهای هوش مصنوعی برای جذب کاربر به درصدهای «صرفهجویی» متکی هستند. این اعداد اغلب نتیجه مقایسه یک اجرای واقعی با یک سناریوی خیالی هستند؛ سناریویی که در آن فرض میشود تمام وظایف به یک مدل پرچمدار (Flagship) ارسال شدهاند. این رویکرد باعث ایجاد بنچمارکی میشود که بیشتر شبیه به آینهای برای بازتاب دادن فرضیات توسعهدهنده است تا یک اندازهگیری علمی. در همین راستا، ابزارهای دیگری نیز سعی کردهاند با متدهای مختلف هزینه را کاهش دهند، مشابه آنچه در رویکرد Tokdiet برای کاهش ۷۱ درصدی هزینه استنتاج شاهد بودیم.
طبق پست نویسنده در dev.to، فایل README اولیه ORA ادعا میکرد که این ابزار ۶۸٪ ارزانتر از استفاده از یک مدل پرچمدار است. این عدد از یک مثال واحد به دست آمده بود: یک زیر-وظیفه ارزان، سه مورد میانرده و یک مورد پرچمدار. این مثال سپس بدون هیچ تست سختگیرانهای، به عنوان یک معیار جهانی در نظر گرفته شد. در این محاسبه، از ضرایب هزینه ۱، ۲ و ۱۰ استفاده شده بود که منجر به مجموع ۱۷ واحد به جای ۵۰ واحد شد. نتیجه ۶۶٪ در نهایت به ۶۸٪ گرد شد و چون کسی واقعاً چیزی را اندازه نگرفته بود، این عدد هرگز مورد تردید قرار نگرفت.
سازوکار عملکرد ORA
ORA با تقسیم یک پرامپت سطح بالا به گرافی از زیر-وظایف مستقل عمل میکند. این ابزار از طریق دستور go install github.com/vystartasv/ora/cmd/ora@latest قابل نصب است و میتوان از آن برای کارهایی نظیر ساخت سیستمهای ورود با JWT، بازنویسی APIها برای هندلرهای async یا طراحی شمای دیتابیسهای SaaS چند-مستأجری استفاده کرد.
این سیستم سپس منطق مسیریابی (Routing) خاصی را اعمال میکند:
- لایه ارزان (Cheap Tier): وظایف مربوط به جستوجوی ساده و تحقیق اولیه را بر عهده دارد.
- لایه متوسط (Mid Tier): به طور اختصاصی برای تولید کد و بازبینی (Review) آن در نظر گرفته شده است.
- لایه پرچمدار (Flagship Tier): برای عیبیابیهای پیچیده و طراحی معماری رزرو شده است.
در این لایهبندی، استفاده از مدلهای بهینهای که ارزش اقتصادی بیشتری ارائه میدهند کلیدی است؛ برای مثال، مدلهایی مانند DeepSeek V4 Flash که ارزش ۱۲ برابری نسبت به مدلهای پریمیوم دارند، گزینههای ایدهآلی برای لایههای ارزان و متوسط هستند.
علاوه بر مسیریابی، این سیستم از چهار مکانیسم کلیدی بهره میبرد:
- تجزیه (Decompose): یک مدل زبانی بزرگ (LLM) وظایف را به تکههای کوچک، مستقل و قابلتأیید تقسیم میکند.
- تفویض (Delegate): سیستم عاملهای فرعی (Subagents) ایجاد کرده یا عاملهای CLI را فراخوانی میکند و در صورت اجازه گراف، آنها را بهصورت موازی اجرا میکند.
- فشردهسازی (Compress): کلمات اضافی و پرکننده را از هر دو بخش پرامپت و خروجی حذف میکند تا مصرف توکنها کاهش یابد.
- تلفیق (Reconcile): نتایج را تأیید و ادغام کرده و گزارش نهایی را در یک فایل
.ora-report.jsonثبت میکند.
ORA بهگونهای طراحی شده است که با عاملهای موجود که فایلهای قوانین (Rules) را میخوانند، سازگار باشد. این موارد شامل Claude Code، Codex، Pi، Cursor، Cline و Hermes است. همچنین سازگاری با فایلهای CLAUDE.md ، .cursor/rules/ ،.clinerules/ ،دستورات Copilot و مهارتهای Hermes را شامل میشود.
تغییر رویکرد در اندازهگیری
به جای ادعای تئوریک ۶۸٪ صرفهجویی، ORA اکنون فقط هزینههای واقعی هر اجرا را گزارش میکند. توسعهدهنده محاسبه صرفهجویی را از فایل orchestrate.go پاک کرد، این فیلد را از ساختار گزارش حذف کرد و جدول مربوطه را از README زدود.
این اصلاح ضروری بود زیرا مدلهای پرچمدار فقط توکن گرانتری ندارند، بلکه در هر توکن کار بیشتری انجام میدهند. برای مثال، یک مدل ارزان ممکن است ۲,۰۰۰ توکن مصرف کند، شکست بخورد و دو بار تلاش مجدد کند، در حالی که یک مدل پرچمدار ممکن است تنها با ۴۰۰ توکن پاسخ درست را بدهد. یک ضریب هزینه ساده برای هر زیر-وظیفه، این واقعیت را نادیده میگیرد.
فرمت جدید گزارشدهی، دادههای خام API را جایگزین فرضیات میکند. برای مثال، یک گزارش معمولی اکنون به سادگی ذکر میکند: «۵ زیر-وظیفه · ۴ مدل · ۰.۰۰۳۸ دلار».
این تغییر نشاندهنده تنشی رو به رشد در تجربه توسعهدهندگان هوش مصنوعی است. وقتی ادعاهایی مثل «X٪ سریعتر» یا «Y٪ ارزانتر» بر اساس فرضیات باشند، به داستانهای تبلیغاتی تبدیل میشوند. نویسنده استدلال میکند هر معیاری که نیاز به اجرای سناریویی داشته باشد که «هرگز رخ نداده است»، یک داستان است، نه یک اندازهگیری. استاندارد جدید برای ORA این است که هر فرد غریبهای باید بتواند هزینه را بدون باور کردن حرف نویسنده، بازتولید کند.
برای کسانی که گردشهای کاری عاملمحور (Agentic) میسازند، این به معنای فاصله گرفتن از بهینگی تئوری و حرکت به سمت حسابداری سختگیرانه توکنها است. اگر در حال تصمیمگیری برای پذیرش یک ارکستراتور جدید هستید، تنها معیاری که بر سود خالص شما اثر میگذارد، هزینه واقعی یک اجراست.
سورسکد این پروژه تحت لایسنس MIT در گیتهاب در مسیر vystartasv/ora در دسترس است تا ببینید منطق مسیریابی چگونه لایههای مختلف مدلها را در نسخه v0.1.0 مدیریت میکند.
گام بعدی شما
- اگر از ابزارهایی مثل Cursor یا Cline استفاده میکنید، بررسی کنید که آیا توزیع وظایف شما بین مدلهای مختلف بهینه است یا خیر.
- سورسکد ORA را در گیتهاب بررسی کنید تا ببینید منطق مسیریابی بین لایههای مختلف مدلها چگونه پیاده شده است.
- در گزارشهای هزینه مدلهای خود، به جای «درصد صرفهجویی»، روی «هزینه هر عملیات موفق» تمرکز کنید.
اما داستان سختافزاری این بهینهسازیها حتی شگفتانگیزتر است — به تحلیل ما دربارهی تأثیر تراشههای جدید بر هزینه استنتاج مراجعه کنید.
گفتگو