عامل‌های کدنویسی قبل از تولید هر خط کد، حجم قابل‌توجهی متن می‌خوانند: فایل‌های منبع، شرح تیکت‌ها، لاگ‌های ساخت، گزارش‌های کیفیت و هشدارهای وابستگی. بخش عمده هزینهٔ مدل‌ها از همین متنِ قبل از تولید Pull Request ناشی می‌شود و به‌خاطر ساختارِ تکراریِ داده‌ها قابل کاهش است.

اهمیت قالب خروجی ابزارها

تیم‌ها معمولاً کنترل هزینه را با انتخاب مدل، کوتاه‌سازی پرامپت یا تنظیم نرخ درخواست‌ها دنبال می‌کنند، اما یک اهرم کمتر استفاده‌شده بین عامل‌ها و ابزارها قرار دارد: قالبی که داده‌ها به مدل تحویل داده می‌شوند. ابزارهایی که فهرستی از رکوردهای هم‌شکل تولید می‌کنند، با ارسال JSON حاوی نام فیلدها و نشانه‌گذاری ساختاری، به‌طور مکرر هزینهٔ توکن برای ساختارپردازی می‌پردازند. محتوای مفید همان مقادیر است؛ بخش زیادی از متن صرف سربار ساختاری می‌شود. برای مثال، هنگام پردازش مکرر رکوردها، عامل‌ها بارها برای نام فیلدها هزینه می‌دهند. برای توضیح بیشتر، اینجا کلمهٔ پرامپت اشاره شده که نقش مهمی در مصرف زمینه (context) دارد.

نمایی از لاگ‌ها و خطاهای یک ابزار کدنویسی

نمونه‌ای از مشکل

یک ورودی معمولی در JSON ممکن است چنین ساختاری داشته باشد:

{
  "key": "AZ1002fQ9x",
  "severity": "BLOCKER",
  "component": "src/main/java/com/acme/UserRepo.java",
  "line": 29,
  "status": "OPEN"
}

این قالب برای خوانایی انسانی و برخی سیستم‌ها مناسب است، اما وقتی عامل باید ده‌ها یا چندصد رکورد را بخواند، تکرار نام فیلدها فضای زیادی از زمینه را اشغال می‌کند — فضای قابل‌استفاده برای شواهد مرتبط‌تر، دستورالعمل یا کد منبع کاهش می‌یابد.

TOON: راه‌حلی مبتنی بر اسکِما برای کاهش توکن

رویکرد Token-Oriented Object Notation (TOON) ابتدا یک هدر شبیه اسکِما برای آرایهٔ یکنواخت ارسال می‌کند و سپس هر رکورد را به‌صورت ردیف می‌فرستد؛ یعنی نام فیلدها فقط یک‌بار ظاهر می‌شوند و سپس مقادیر در ردیف‌ها قرار می‌گیرند. برای مجموعه‌های جدول‌مانند یکنواخت، TOON نسبت به JSON کدگذاری کم‌هدررفت‌تری ارائه می‌دهد و تعداد کاراکترها و به‌تبع آن توکن‌های مصرفی را کاهش می‌دهد.

مزیت فنی فراتر از صرفه‌جویی در متن است: اسکِمای صریح به مدل مجموعهٔ مشخصی از فیلدها می‌دهد و این ثبات خواندن، بازبینی و اعتبارسنجی خروجی را قابل‌پیش‌بینی‌تر می‌کند — به‌ویژه وقتی عامل‌ها بارها داده را می‌خوانند و اصلاح می‌کنند.

لینک‌های مرجع

چگونه صرفه‌جویی را اندازه‌گیری کنیم

واحد تحلیل باید خروجی واقعی ابزار تیم و مدلِ مورد استفاده باشد. شمارش کاراکتر سیگنال اولیه است، اما نحوهٔ تبدیل به توکن بین مدل‌ها متفاوت است؛ بنابراین نمونهٔ نماینده بگیرید، آن را با توکنیزر مدل هدف اندازه‌گیری کنید و با حالت فعلی مقایسه نمایید.

مثال با Sonar CLI:

# خروجی JSON پیش‌فرض
sonar list issues -p my-org_my-app --severities BLOCKER,CRITICAL --format json > issues.json

# بررسی همان داده با TOON CLI
npx @toon-format/cli issues.json --stats

# ارسال خروجی فشرده و بدون اتلاف مستقیم به عامل
sonar list issues -p my-org_my-app --severities BLOCKER,CRITICAL --format toon

دستور اول مبنای مقایسه را فراهم می‌کند، دستور دوم صرفه‌جویی واقعی را نشان می‌دهد و دستور سوم زمانی کاربرد دارد که مصرف‌کننده عامل باشد. در یک نمونهٔ 25 رکوردی، TOON حدود 49٪ کاراکتر کمتر نسبت به JSON خوانای قالب‌بندی‌شده و 33٪ کمتر نسبت به JSON فشرده نشان داد؛ بنچ‌مارک‌ها نیز کاهش مصرف توکن برای مجموعه‌های یکنواخت را تأیید می‌کنند.

قواعد ساده برای انتخاب قالب مناسب

  • برای انسان‌ها: اگر هدف اسکن سریع در ترمینال است، از جدول یا نمایش خلاصه استفاده کنید.
  • برای اسکریپت‌ها و API: وقتی ساختار نامنظم یا تو در تو دارید، JSON استاندارد مناسب‌تر است.
  • برای مدل‌های زبانی: اگر مدل باید رکوردهای زیادی با همان فیلدها بخواند، قالب‌های فشرده و مبتنی‌بر اسکِما مانند TOON را در نظر بگیرید.

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

هشدارهای مهندسی

  • فشردگی نباید کیفیت شواهد یا توانایی عامل برای تصمیم‌گیری را تضعیف کند. متن ارزان‌تر که منجر به تصمیم ضعیف‌تر شود، صرفه‌جویی واقعی نیست.
  • برای داده‌های نامنظم یا تو در تو، JSON ممکن است همچنان بهترین گزینه باشد. انتخاب باید براساس شکل داده و مخاطب انجام شود، نه صرفاً کاهش کاراکتر.
  • نتایج را همیشه با توکنیزر مدل هدف اندازه‌گیری کنید؛ بنچ‌مارک‌های عمومی فقط جهت را نشان می‌دهند.

گام‌های عملی برای تیم‌ها

  1. خروجی ابزارهای اصلی را شناسایی و نمونه‌برداری کنید (فهرست اشکال، گزارش‌های تحلیل، هشدارهای وابستگی).
  2. برای هر نوع داده، مصرف‌کننده را مشخص کنید: انسان، اسکریپت یا مدل زبانی.
  3. نمونه‌ها را با فرمت‌های موجود (JSON، JSON فشرده، TOON یا قالب دلخواه) توکنیزه و مقایسه کنید.
  4. مکانیسمی پیاده‌سازی کنید تا بر اساس مصرف‌کننده، قالب خروجی انتخاب شود و در صورت مصرف توسط عامل، قالب فشرده‌تری ارائه شود.
  5. پس از اعمال تغییر، معیارهای کیفی (دقت بازیابی، نرخ خطا) را پایش کنید تا از حفظ کیفیت اطمینان حاصل شود.

با گسترش نقش عامل‌ها در گردش‌های توسعه، انتخاب آگاهانهٔ قالب خروجی می‌تواند یکی از مؤثرترین و کم‌هزینه‌ترین روش‌های بهینه‌سازی مصرف توکن باشد — راهکاری مهندسی که هم هزینه را کاهش می‌دهد و هم کیفیت تصمیم‌گیری را حفظ می‌کند.