AI Cost Attribution: اعرف كل ميزة بتصرف كام

مستوى القارئ: متوسط

لو فاتورة الـ AI بتزيد ومش عارف السبب، المقال ده هيخليك تعرف أي مستخدم وأي ميزة وأي موديل صرفوا الفلوس بالظبط قبل ما تستنى آخر الشهر.

المشكلة باختصار

الطريقة الشائعة إن الفريق يفتح لوحة الفوترة آخر الأسبوع، يشوف رقم كبير، وبعدها يبدأ التخمين: هل السبب الشات؟ هل السبب تلخيص التذاكر؟ هل موديل أغلى اتستخدم بالغلط؟ الطريقة دي بتفشل لأن الفاتورة بتقول لك المبلغ، لكنها غالبًا لا تقول لك سياق المنتج اللي سبب المبلغ.

ركز في السيناريو ده: عندك SaaS فيه 3 ميزات AI. ميزة تلخص تذاكر الدعم، ميزة تكتب ردودًا مقترحة، وميزة تبحث في الوثائق. لو عندك 50 ألف طلب في اليوم وزادت التكلفة من 18 دولار إلى 42 دولار يوميًا، محتاج تعرف الزيادة جاية منين خلال دقائق، مش بعد اجتماع طويل.

الفكرة بمثال بسيط

اعتبر إن عندك كارت ائتمان واحد للشركة. لو كل الموظفين اشتروا أدوات مختلفة بنفس الكارت، كشف الحساب هيقول لك إجمالي المبلغ، لكن مش هيقول لك بسهولة إن فريق الدعم صرف 70% على أداة معينة. الحل إن كل عملية شراء تتسجل معها: مين اشترى، لأي سبب، وبأي مشروع.

AI Cost Attribution هو نفس الفكرة. كل طلب للنموذج لازم يتسجل معه المستخدم، اسم الميزة، اسم الموديل، عدد input tokens، عدد output tokens، والتكلفة التقريبية. بعد كده تقدر تسأل: ميزة support-summary صرفت كام النهارده؟ هل مستخدم واحد عمل spike؟ هل gpt-5-mini كفاية بدل موديل أغلى؟

ما الذي تسجله فعلاً؟

الافتراض إن تطبيقك بيستخدم OpenAI Responses API أو واجهة مشابهة بترجع كائن usage. توثيق OpenAI يوضح إن usage يحتوي input_tokens وoutput_tokens وtotal_tokens. كمان Usage API وCosts endpoint موجودين للتجميع على مستوى المنظمة، لكنهم لا يعرفون اسم الميزة داخل تطبيقك إلا لو أنت سجلته.

أفضل سجل مبدئي يكون بالشكل ده:

• request_id: رقم الطلب الداخلي.
• user_id: المستخدم أو الحساب.
• feature: مثل support_summary أو doc_search_answer.
• model: اسم الموديل المستخدم.
• input_tokens وoutput_tokens: من استجابة الـ API.
• estimated_cost_usd: حساب تقريبي حسب سعر الموديل وقت التشغيل.

مثال Node.js قابل للتطبيق

الكود التالي لا يحاول يبني billing system كامل. هو يضيف طبقة تسجيل صغيرة حول استدعاء النموذج. الأرقام هنا مثالية: لو الموديل سعره 0.25 دولار لكل مليون input tokens و2.00 دولار لكل مليون output tokens، طلب فيه 2400 input و650 output يكلف تقريبًا 0.0019 دولار. الرقم صغير، لكن 100 ألف طلب يوميًا يحول التفاصيل الصغيرة لقرار منتج حقيقي.

import OpenAI from "openai";
import { randomUUID } from "crypto";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const PRICE_PER_1M = {
  "gpt-5-mini": { input: 0.25, output: 2.00 }
};

function estimateCost(model, usage) {
  const price = PRICE_PER_1M[model];
  if (!price || !usage) return null;

  const inputCost = (usage.input_tokens / 1_000_000) * price.input;
  const outputCost = (usage.output_tokens / 1_000_000) * price.output;
  return Number((inputCost + outputCost).toFixed(6));
}

async function runAiFeature({ userId, feature, input }) {
  const requestId = randomUUID();
  const model = "gpt-5-mini";

  const response = await client.responses.create({
    model,
    input
  });

  const usage = response.usage;
  const estimatedCostUsd = estimateCost(model, usage);

  await db.ai_cost_events.insert({
    request_id: requestId,
    user_id: userId,
    feature,
    model,
    input_tokens: usage?.input_tokens ?? 0,
    output_tokens: usage?.output_tokens ?? 0,
    estimated_cost_usd: estimatedCostUsd,
    created_at: new Date()
  });

  return response.output_text;
}

قياس قبل وبعد

قبل التسجيل، معرفة مصدر زيادة التكلفة ممكن تاخد 8 ساعات: تصدير usage، مقارنة logs، وسؤال الفريق عن آخر deploy. بعد التسجيل، query واحدة على جدول ai_cost_events تكشف أن support_summary صرفت 63% من تكلفة اليوم، وأن 12 حسابًا فقط سببوا أغلب الزيادة. ده لا يخفض الفاتورة وحده، لكنه يخليك تتحرك بدقة.

استعلام بسيط يكفي كبداية:

SELECT
  feature,
  model,
  COUNT(*) AS requests,
  SUM(input_tokens) AS input_tokens,
  SUM(output_tokens) AS output_tokens,
  ROUND(SUM(estimated_cost_usd), 4) AS cost_usd
FROM ai_cost_events
WHERE created_at >= NOW() - INTERVAL '1 day'
GROUP BY feature, model
ORDER BY cost_usd DESC;

الـ trade-off هنا

بتكسب رؤية دقيقة على مستوى المنتج: أي ميزة تصرف، أي موديل أغلى من اللازم، وأي مستخدم عامل ضغط غير طبيعي. بتخسر بعض البساطة: جدول إضافي، تحديث أسعار الموديلات، واحتمال اختلاف بسيط بين تقديرك الداخلي والفاتورة النهائية. توثيق OpenAI نفسه ينبه أن Usage API قد لا يطابق Costs endpoint دائمًا بسبب فروق التسجيل، لذلك خليك واضح: السجل الداخلي للتشغيل واتخاذ القرار، وCosts endpoint أو لوحة الفوترة للمحاسبة النهائية.

أفضل طريقة عملية: حدّث جدول الأسعار في config مرة يوميًا أو يدويًا عند تغيير الموديل. لا تكتب السعر داخل الكود في الإنتاج. الكود السابق للتوضيح فقط.

متى لا تستخدم هذه الطريقة

لا تبدأ بها لو تطبيقك في مرحلة تجربة وفيه أقل من 100 طلب AI يوميًا؛ جدول بسيط في لوحة الفوترة يكفي غالبًا. لا تستخدمها كبديل عن rate limits، لأنها تكشف الإنفاق بعد حدوثه ولا تمنع مستخدمًا من حرق الميزانية. ولا تعتمد عليها كمحاسبة قانونية نهائية لو عندك فواتير عملاء، لأنها تقديرية وتحتاج مطابقة دورية مع مصدر التكلفة الرسمي.

المصادر

• OpenAI Responses API Reference
• OpenAI Usage and Costs API Reference
• OpenAI API Pricing

الخطوة التالية

افتح أول استدعاء AI في تطبيقك، وسجل feature وmodel وusage في جدول واحد لمدة 24 ساعة. بعد يوم، شغّل استعلام التجميع، وخد قرارًا واحدًا: أي ميزة تحتاج موديل أرخص أو prompt أقصر؟