كيف تتعامل نماذج اللغات الكبيرة مع قواعد الأعمال ومنطق سير العمل

لماذا استدلال قواعد الأعمال أكثر من توليد شفرة

عندما يسأل الناس ما إذا كان نموذج لغة كبير يمكن "الاستدلال حول قواعد الأعمال"، فعادة ما يقصدون شيئًا أكثر تطلبًا من "هل يستطيع كتابة عبارة if/else". استدلال قواعد الأعمال هو القدرة على تطبيق السياسات بثبات، وشرح القرارات، والتعامل مع الاستثناءات، والبقاء متوافقًا مع خطوة سير العمل الحالية—خاصة عندما تكون المدخلات ناقصة أو فوضوية أو متغيرة.

الاستدلال مقابل إصدار الشفرة

توليد الشفرة يتعلق في المقام الأول بإنتاج بناء جملة صحيح في لغة الهدف. استدلال القواعد يتعلق بالحفاظ على النية.

يمكن للنموذج أن ينتج شفرة صحيحة تمامًا ومع ذلك تنتج نتيجة أعمال خاطئة لأن:

• نص السياسة غامض ("العميل الأخير"، "عالي المخاطر"، "المستندات المعتمدة").
• القواعد تتضارب، والأسبقية غير واضحة.
• الحالات الطرفية غير مذكورة (استردادات جزئية، تكرارات، عطلات/عطلات رسمية).
• حالة سير العمل تغير ما يجب أن يحدث بعد ذلك (الاستلام مقابل المراجعة مقابل الموافقة النهائية).

بعبارة أخرى، الصواب ليس "هل يترجم؟" بل هو "هل يطابق ما سيقرره العمل، في كل مرة، وهل يمكن إثبات ذلك؟"

ماذا نتوقع من نماذج اللغات الكبيرة

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

لذلك الهدف ليس "ترك النموذج ليقرر"، بل تزويده بهيكل وفحوصات ليكون مساعدًا موثوقًا.

ما الذي سيفعله بقية هذه المقالة

منهج عملي يبدو كسلسلة خطوات (pipeline):

1. تحويل نص السياسة إلى تمثيلات قواعد قابلة للاستخدام.
2. تتبع حالة سير العمل حتى تظل القرارات متسقة عبر الخطوات.
3. استخدام أنماط استعلام لفرض الأولويات والاستثناءات والتفسيرات.
4. تأصيل القرارات بالأدوات والاسترجاع (باستخدام البيانات المعتمدة فقط).
5. تقييد المخرجات بالشماتل لتقليل الغموض.
6. التحقق والاختبار والمراقبة حتى تُكتشف الأخطاء قبل الإصدار.

هذا هو الفرق بين مقطع شفرة ذكي ونظام يمكنه دعم قرارات أعمال حقيقية.

قواعد الأعمال وسير العمل: مراجعة سريعة وبسيطة

قبل الحديث عن كيفية "استدلال" النموذج، من المفيد فصل شيئين غالبًا ما تدمجهما الفرق: قواعد الأعمال وسير العمل.

ما هي قواعد الأعمال؟

قواعد الأعمال هي جمل القرار التي تريد منظمتك فرضها باستمرار. تظهر كسياسات ومنطق مثل:

• الأهلية: من المؤهل للاستفادة أو الخطة أو الميزة؟
• التسعير: أي خصم يطبق ومتى؟
• الموافقات: متى يلزم مراجعة المدير؟
• الامتثال: ما الذي يجب تسجيله أو حذفه أو منعه؟

عادةً تُصاغ القواعد على شكل "IF X, THEN Y" (أحيانًا مع استثناءات)، وينبغي أن تنتج نتيجة واضحة: قبول/رفض، سعر A/سعر B، طلب مزيد من المعلومات، وهكذا.

ما هو سير العمل؟

سير العمل هو العملية التي تنقل العمل من البداية إلى النهاية. هو أقل عن تقرير ما هو المسموح وأكثر عن ما الذي يحدث بعد ذلك. غالبًا ما يتضمن سير العمل:

• الحالات: مُقدّم → قيد المراجعة → موافق/مرفوض → مُكتمل
• الخطوات والتسليمات: دعم العملاء → المالية → العميل
• أحداث زمنية: تذكيرات، اتفاقيات مستوى الخدمة، الإلغاء التلقائي بعد 14 يومًا
• المخرجات: نماذج، مرفقات، رموز سبب، ملاحظات تدقيق

مثال صغير: طلبات الاسترداد

تخيل طلب استرداد.

مقتطف قاعدة: "الاستردادات مسموحة خلال 30 يومًا من الشراء. استثناء: التنزيلات الرقمية غير قابلة للاسترداد بمجرد الوصول إليها. استثناء: يجب تصعيد عمليات الاسترداد المتعلقة بمعاملات رد المبالغ (chargebacks)."

مقتطف سير العمل:

1. يقدّم العميل الطلب (الحالة: مُقدّم).
2. يتحقق النظام من تاريخ الشراء ونوع المنتج (الحالة: قيد المراجعة).
3. إذا كان مؤهلاً، أصدر الاسترداد وأخطر العميل (الحالة: مكتمل).
4. إذا كانت هناك عملية رد مبالغ، أعد التوجيه إلى المالية للتحقيق (الحالة: مصعَّد).

لماذا القواعد أصعب مما تبدو

تصبح القواعد معقدة عندما تتضارب ("عملاء VIP دائمًا يحصلون على استرداد" مقابل "التنزيلات الرقمية لا تُرد"), تعتمد على سياق مفقود (هل تم الوصول إلى التنزيل؟)، أو تخفي حالات طرفية (الحزم، الاستردادات الجزئية، قوانين إقليمية). تضيف سير العمل طبقة أخرى: يجب أن تظل القرارات متسقة مع الحالة الحالية، والإجراءات السابقة، والمواعيد النهائية.

كيف "يستدل" النموذج: مطابقة النمط مع هيكل مفيد

نماذج اللغات لا "تفهم" قواعد الأعمال كما يفهمها الإنسان. إنها تولد أكثر الكلمات احتمالًا التالية بناءً على أنماط تعلمتها من كميات كبيرة من النصوص. لهذا يمكن أن يبدو النموذج مقنعًا حتى وهو يُخمن—أو عندما يملأ بهدوء تفاصيل مفقودة لم تُقدم.

هذا القيد مهم لسياقات سير العمل ومنطق القرار. قد يطبق النموذج قاعدة تبدو صحيحة ("الموظفون دائمًا يحتاجون موافقة المدير") حتى لو كانت السياسة الحقيقية لها استثناءات ("فقط فوق 500$" أو "فقط للمقاولين"). هذه حالة فشل شائعة: تطبيق القاعدة بثقة لكنه خطأ.

لماذا ما زالوا مفيدين لقواعد الأعمال

حتى بدون "فهم" حقيقي، يمكن لنماذج اللغات الكبيرة المساعدة عندما تعاملها كمساعد منظم:

• تلخيص سياسات طويلة إلى لغة أوضح للمراجعة
• تحويل نص فوضوي إلى حقول متناسقة (من، ماذا، العتبة، الاستثناء، تاريخ السريان)
• التحقق من قرار مقترح مقابل القواعد المعلنة ("أي بند يدعم هذا؟")

المفتاح هو وضع النموذج في موقع لا يمكنه فيه الانجراف بسهولة إلى الارتجال.

تقييد النموذج حتى لا ينحرف

طريقة عملية لتقليل الغموض هي مخرجات مقيدة: اجعل النموذج يرد بمخطط أو قالب ثابت (مثل JSON بحقول محددة، أو جدول بأعمدة مطلوبة). عندما يضطر النموذج لملء rule_id, conditions, exceptions, وdecision يصبح من الأسهل رصد الثغرات والتحقق تلقائيًا من المخرجات.

الأنماط المقيدة تجعل أيضًا الأمر أوضح عندما لا يعرف النموذج شيئًا. إذا كان حقل مطلوب مفقودًا، يمكنك فرض سؤال متابعة بدلاً من قبول إجابة مرتجلة.

النتيجة: استدلال LLM يُرى أفضل كالتوليد المعتمد على الأنماط الموجهة بالهيكل—مفيد لتنظيم ومراجعة القواعد، لكنه محفوف بالمخاطر إذا اعتُبر منطقًا نهائيًا.

تحويل نص السياسة الفوضوي إلى تمثيلات قواعد قابلة للاستخدام

وثائق السياسات مكتوبة للبشر: تخلط الأهداف والاستثناءات و"الفطرة السليمة" في نفس الفقرة. يمكن للـLLM تلخيص هذا النص، لكنه يتبع القواعد بشكل أكثر موثوقية عندما تحول السياسة إلى مدخلات صريحة وقابلة للاختبار.

كيف تبدو القواعد "القابلة للاستخدام"

التمثيلات الجيدة للقواعد تتشارك صفتين: أنها غير غامضة ويمكن التحقق منها.

اكتب القواعد كتعابير يمكن اختبارها:

• IF/THEN للقرارات (الأهلية، التوجيه، الموافقات)
• MUST / MUST NOT للقيود الصارمة
• MAY للخيارات المسموح بها (تحتاج غالبًا لكاسر تعادل)

يمكن تزويد القواعد للنموذج بعدة أشكال:

• نقاط بلغة طبيعية (الأسرع ولا تزال منظمة)
• جدول (ممتاز للسياسات المعتمدة على العتبات)
• YAML/JSON (الأفضل عند الرغبة في مخرجات مقيدة والتحقق الآلي)

التعامل مع التضارب والأولوية

السياسات الحقيقية تتضارب. عندما يتعارض حكمان، يحتاج النموذج إلى مخطط أولوية واضح. نُهج شائعة:

• الخاص يتفوق على العام (الاستثناء يبطل الافتراضي)
• السلطة الأعلى تفوز (القانون/الامتثال فوق تفضيل فريق)
• الأحدث يفوز (الإصدار الأحدث من السياسة يبطل الأقدم)
• أرقام أولوية صريحة (الأكثر موثوقية)

صرّح عن قاعدة حل التضارب مباشرة، أو شفرها (مثال: priority: 100). وإلا قد "يُجمّع" الـLLM بين القواعد.

مثال: تحويل فقرة إلى قائمة قواعد

نص السياسة الأصلي:

“Refunds are available within 30 days for annual plans. Monthly plans are non-refundable after 7 days. If the account shows fraud or excessive chargebacks, do not issue a refund. Enterprise customers need Finance approval for refunds over $5,000.”

Structured rules (YAML):

rules:
  - id: R1
    statement: "IF plan_type = annual AND days_since_purchase <= 30 THEN refund MAY be issued"
    priority: 10
  - id: R2
    statement: "IF plan_type = monthly AND days_since_purchase > 7 THEN refund MUST NOT be issued"
    priority: 20
  - id: R3
    statement: "IF fraud_flag = true OR chargeback_rate = excessive THEN refund MUST NOT be issued"
    priority: 100
  - id: R4
    statement: "IF customer_tier = enterprise AND refund_amount > 5000 THEN finance_approval MUST be obtained"
    priority: 50
conflict_resolution: "Higher priority wins; MUST NOT overrides MAY"

الآن النموذج لا يخمن ما الذي يهم—إنه يطبق مجموعة قواعد يمكنك مراجعتها، اختبارها، وإصدار نسخ لها.

تتبّع حالة سير العمل حتى يظل النموذج متسقًا

سير العمل ليس مجرد مجموعة قواعد؛ إنه تسلسل أحداث حيث تغيّر الخطوات المبكرة ما يجب أن يحدث لاحقًا. تلك "الذاكرة" هي الحالة: الحقائق الحالية عن الحالة (من قدّم ماذا، ما الذي تم الموافقة عليه بالفعل، ما الذي ينتظر، وما المواعيد النهائية المطبقة). إذا لم تتبّع الحالة صراحة، تنهار سير العمل بطرق متوقعة—موافقات مكررة، تخطي فحوصات مطلوبة، عكس قرارات، أو تطبيق قاعدة خاطئة لأن النموذج لا يستطيع استنتاج ما حدث بالفعل موثوقًا.

ماذا تعني "الحالة" بلغة بسيطة

فكّر في الحالة كلوحة تتبع لسير العمل. تجيب: نحن أين الآن؟ ماذا تم؟ ما المسموح به بعد؟ لِـ LLM، وجود ملخص حالة واضح يمنعه من إعادة إعادة فتح خطوات سابقة أو التخمين.

كيفية تمرير الحالة إلى النموذج

عند استدعاء النموذج، أرفق حمولة حالة مضغوطة مع طلب المستخدم. الحقول المفيدة:

• اسم الخطوة والحالة (مثال: manager_review: approved, finance_review: pending)
• معرّفات ثابتة (معرف الطلب، معرف الموظف) حتى لا يخلط النموذج بين الحالات
• طوابع زمنية (مقدم في، آخر تحديث) لحل حالات "الأحدث يفوز"
• أعلام (استثناءات سياسة، مستندات مفقودة، يتطلب تصعيد)

تجنّب إلقاء كل الرسائل التاريخية. بدلًا من ذلك، قدّم الحالة الحالية بالإضافة إلى سجل تدقيق قصير للانتقالات الرئيسية.

احتفظ بمصدر واحد للحقيقة

عامل محرك سير العمل (قاعدة بيانات، نظام تذاكر، أو مُنسق) كمصدر واحد للحقيقة. يجب أن يقرأ الـLLM الحالة من ذلك النظام ويُقترح الإجراء التالي، لكن يجب أن يكون النظام هو السلطة التي تسجل الانتقالات. هذا يقلل انحراف الحالة، حيث يحيد سرد النموذج عن الواقع.

مثال: لقطة حالة تدفق الموافقة

{
  "request_id": "TRV-10482",
  "workflow": "travel_reimbursement_v3",
  "current_step": "finance_review",
  "step_status": {
    "submission": "complete",
    "manager_review": "approved",
    "finance_review": "pending",
    "payment": "not_started"
  },
  "actors": {
    "employee_id": "E-2291",
    "manager_id": "M-104",
    "finance_queue": "FIN-AP"
  },
  "amount": 842.15,
  "currency": "USD",
  "submitted_at": "2025-12-12T14:03:22Z",
  "last_state_update": "2025-12-13T09:18:05Z",
  "flags": {
    "receipt_missing": false,
    "policy_exception_requested": true,
    "needs_escalation": false
  }
}

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

أنماط الاستعلام التي تحسن الالتزام بالقواعد والقرارات

الاستعلام الجيد لا يطلب إجابة فحسب—إنه يحدد توقعات كيفية تطبيق النموذج لقواعدك وكيفية الإبلاغ عن النتيجة. الهدف قرارات قابلة للتكرار، لا بلاغة ذكية.

1) توجيه الدور: عيّن وظيفة لا إحساسًا عامًا

امنح النموذج دورًا محددًا مرتبطًا بعمليتك. ثلاثة أدوار تعمل جيدًا معًا:

• محلل السياسات: يفسّر نص القاعدة ويربطها بالحالة الحالية.
• المدقق: يتحقق من القرار مقابل المتطلبات ويشير إلى المدخلات المفقودة.
• الوكيل: يتخذ الإجراء التالي في سير العمل (إنشاء تذكرة، صياغة بريد إلكتروني، ضبط حالة).

يمكن تشغيلها بالتسلسل ("محلل → مدقق → وكيل") أو طلب كل المخرجات في رد منظم واحد.

2) تعليمات خطوة بخطوة (بدون طلب التفكير الخفي)

بدلًا من طلب "سلسلة التفكير"، حدّد خطوات ونتائج مرئية:

1. حدد القواعد ذات الصلة.
2. استخرج المدخلات المطلوبة من الحالة.
3. طبّق القواعد حسب الأولوية.
4. قدّم قرارًا والخطوة التالية.

هذا يحافظ على تنظيم النموذج ويبقي التركيز على المخرجات: أي قواعد استُخدمت وما النتيجة.

3) اطلب مسوغًا منظمًا: معرفات القواعد + الأدلة

التفسيرات الحرة تنحرف. اطلب مبررًا موجزًا يشير إلى المصادر:

• معرفات القواعد المستخدمة (مثال: R-12, R-18)
• الأدلة (مقتطفات مقتبسة من نص السياسة وحقول الحالة المحددة)
• الافتراضات (فقط إذا كان هناك مدخل مفقود)

هذا يسرّع المراجعات ويساعد على تصحيح الخلافات.

4) نمط قائمة التحقق: المدخلات، القرار، الاستثناءات، الخطوة التالية

استخدم قالبًا ثابتًا في كل مرة:

• المدخلات المستلمة: …
• المدخلات المفقودة: …
• القرار: قبول/رفض/بحاجة لمراجعة
• مراجع القواعد: [R-…]
• الاستثناءات التي نُظر فيها: …
• الخطوة التالية في سير العمل: تحديث الحالة / طلب معلومات / تصعيد

القالب يقلل الغموض ويدفع النموذج لإظهار الفجوات قبل الالتزام بإجراء خاطئ.

استخدام الأدوات والاسترجاع لتأصيل القرارات في بيانات حقيقية

يمكن للـLLM أن يكتب إجابة مقنعة حتى عندما يفتقد حقائق رئيسية. هذا مفيد للصياغة، لكنه محفوف بالمخاطر لقرارات قواعد الأعمال. إذا اضطر النموذج إلى التخمين بحالة حساب أو فئة عميل أو معدل ضريبي إقليمي، ستحصل على أخطاء تبدو واثقة.

تحل الأدوات ذلك بتحويل "الاستدلال" إلى عملية من خطوتين: جلب الأدلة أولًا، ثم اتخاذ القرار.

الأدوات الشائعة التي تحافظ على صدق النموذج

في الأنظمة الثقيلة بالقواعد وسير العمل، تقوم بعض الأدوات البسيطة بمعظم العمل:

• استعلام قاعدة بيانات (ملف العميل، حالة الحساب، الامتيازات، إجماليات الاستخدام)
• مخزن السياسات/القواعد (نص القاعدة المعتمد، إجراءات مؤرخة، قوائم الاستثناء)
• حاسبة (الرسوم، التقسيم النسبي، الضرائب، نوافذ الزمن، العتبات)
• واجهة تذاكر / API سير العمل (الحالات المفتوحة، مؤقتات SLA، الموافقات، إكمال الخطوة)

المفتاح هو أن النموذج لا "يخترع" حقائق تشغيلية—بل يطلبها.

الاسترجاع: إحضار القواعد ذات الصلة فقط

حتى لو احتفظت بكل السياسات في مخزن مركزي، نادرًا ما تريد لصقها كاملة في الاستعلام. يساعد الاسترجاع في اختيار المقاطع الأكثر صلة بالحالة الحالية—على سبيل المثال:

• سياسة الإلغاء الخاصة بخطة العميل
• بند الامتثال الإقليمي بناءً على الدولة/المنطقة
• قاعدة الاستثناء المتعلقة بوجود رد مبلغ

هذا يقلل التضارب ويمنع النموذج من اتباع قاعدة قديمة لمجرد أنها ظهرت سابقًا في السياق.

تحويل مخرجات الأدوات إلى أدلة قرار

نمط موثوق هو اعتبار نتائج الأدوات كـ دليل يجب على النموذج الاستشهاد به في قراره. مثال:

1. أداة: get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000
2. أداة: retrieve_policies(query="overage fee Business plan") → returns rule: “Overage fee applies above 10,000 units at $0.02/unit.”
3. أداة: calculate_overage(usage=12000, threshold=10000, rate=0.02) → $40.00

الآن القرار ليس تخمينًا: إنه استنتاج مثبت بمدخلات محددة ("past_due"، "12,000 وحدة"، "$0.02/وحدة"). إذا راجعت النتيجة لاحقًا، يمكنك رؤية الحقائق وإصدار القاعدة المحددة المستخدمة—وتصحيح الجزء الصحيح عند التغيير.

المخرجات المقيدة: شماتل تقلل الغموض

النص الحر مرن، لكنه أيضًا أسهل طريقة لانهيار سير العمل. قد يعطي النموذج إجابة "معقولة" غير قابلة للأتمتة ("يبدو جيدًا") أو متقلبة عبر الخطوات ("approve" مقابل "approved"). المخرجات المقيدة تحل ذلك بفرض شكل متوقع لكل قرار.

إرجاع القرارات كـ JSON

نمط عملي هو طلب رد من النموذج ككائن JSON واحد يمكن لنظامك تحليله وتوجيهه:

{
  "decision": "needs_review",
  "reasons": [
    "Applicant provided proof of income, but the document is expired"
  ],
  "next_action": "request_updated_document",
  "missing_info": [
    "Income statement dated within the last 90 days"
  ],
  "assumptions": [
    "Applicant name matches across documents"
  ]
}

هذا البنية تجعل المخرجات مفيدة حتى عندما لا يستطيع النموذج أن يقرّر بالكامل. missing_info وassumptions تحول عدم اليقين إلى متابعات قابلة للتنفيذ بدلًا من تخمين مخفي.

استخدام القوائم المحددة لتقييد النتائج

لتقليل التباين، عرّف قيمًا مسموحًا بها (enums) للحقول الرئيسية. على سبيل المثال:

• decision: approved | denied | needs_review
• next_action: approve_case | deny_case | request_more_info | escalate_to_human

مع القوائم، لا تحتاج الأنظمة اللاحقة لتفسير المترادفات أو علامات الترقيم أو النبرة. فقط تتفرع على قيم معروفة.

لماذا تجعل الشماتل سير العمل أكثر أمانًا

الشماتل تعمل كحواجز حماية. فهي:

• تمنع "الإجابات الجزئية" عن طريق إجبار الحقول المطلوبة.
• تسهّل التدقيق لسبب قرار (عن طريق reasons).
• تُمكّن الأتمتة الموثوقة: الطوابير، الإشعارات، وإنشاء المهام يمكن أن تُشغّل مباشرة من decision وnext_action.
• تدعم التحقق: يمكنك رفض المخرجات التي لا تطابق الشماتل وطلب إعادة المحاولة.

النتيجة: غموض أقل، أخطاء حافة أقل، وقرارات تنتقل بسلاسة عبر سير العمل.

استراتيجيات التحقق: اكتشاف الأخطاء قبل الإطلاق

حتى النموذج المحسّن جيدًا يمكنه "الظهور صوابًا" وهو يتجاهل قاعدة، أو يتخطى خطوة مطلوبة، أو يخترع قيمة. التحقق هو شبكة الأمان التي تحول إجابة معقولة إلى قرار يعتمد عليه.

الفحوص الأولية: تحقق من المدخلات قبل الاستدلال

ابدأ بالتحقق من توفر الحد الأدنى من المعلومات المطلوبة لتطبيق القواعد. يجب أن تُجرى الفحوص قبل أن يتخذ النموذج أي قرار.

الفحوص الشائعة تشمل الحقول المطلوبة (نوع العميل، إجمالي الطلب، المنطقة)، صيغ أساسية (تواريخ، معرّفات، عملة)، ونطاقات مسموح بها (مبالغ غير سالبة، نسب مئوية ≤ 100%). إذا فشل شيء، أعد خطأ واضحًا وقابلًا للتصحيح ("مفقود 'region'; لا يمكن اختيار مجموعة قواعد الضرائب") بدلًا من السماح للنموذج بالتخمين.

الفحوص اللاحقة: تحقق من القرار مقابل القواعد

بعد أن ينتج النموذج نتيجة، تحقق أنها متسقة مع مجموعة قواعدك.

ركز على:

• تغطية القواعد: هل استشهد القرار أو ربط بمراجع القواعد المطبقة، أم أنه تخطى سياسة إلزامية؟
• فحوص التناقض: هل يتعارض المخرج مع المدخلات المذكورة (مثلًا، "approved" بينما شرط حظر صريح موجود)؟
• حالات الحدود: اختبر العتبات مثل (بالضبط $10,000)، الحالات الفارغة ("لا مخالفات سابقة"), وسيناريوهات "فقط فوق الحد".

التحقق الثاني: خطوة مراجعة متعمدة

أضف "مرورًا ثانيًا" يعيد تقييم الإجابة الأولى. يمكن أن تكون مكالمة نموذج أخرى أو نفس النموذج مع موجه متخصّص يدقق الالتزام فقط، لا الإبداع.

نمط بسيط: التمريرة الأولى تنتج قرارًا ومبررًا؛ التمريرة الثانية ترجع إما valid أو قائمة مهيكلة بالفشل (حقول مفقودة، قيود منتهكة، تفسير غامض للقواعد).

التسجيل: اجعل القرارات قابلة للتدقيق

لكل قرار، سجّل المدخلات المستخدمة، نسخة/إصدار القاعدة، ونتائج التحقق (بما في ذلك نتائج التمريرة الثانية). عندما تحدث مشكلة، يتيح ذلك إعادة إنتاج الظروف الدقيقة، تصحيح ربط القاعدة، والتأكد من التصحيح—دون التخمين بما «كان يقصده» النموذج.

الاختبار والمراقبة لثبات القواعد وسير العمل

اختبار ميزات LLM المعتمدة على القواعد وسير العمل يتعلق أقل بـ"هل ولّد شيئًا؟" وأكثر بـ"هل اتخذ نفس القرار الذي سيتخذه إنسان حريص، للسبب الصحيح، في كل مرة؟" الأخبار الجيدة: يمكنك اختباره بنفس الانضباط المستخدم للمنطق التقليدي للقرارات.

اختبارات الوحدة لقواعد الأعمال (التحققات الصغيرة والمتوقعة)

عامل كل قاعدة كدالة: بالنظر إلى مدخلات، يجب أن تُرجع نتيجة يمكن التأكيد عليها.

مثال: لقاعدة استرداد مثل "الاستردادات مسموحة خلال 30 يومًا للبنود غير المفتوحة"، اكتب حالات مركزة بنتائج متوقعة:

• عمر الطلب = 10 أيام، غير مفتوح = true → approve
• عمر الطلب = 10 أيام، غير مفتوح = false → deny
• عمر الطلب = 45 يومًا، غير مفتوح = true → deny
• حالات الحافة: بالضبط 30 يومًا، حقل "غير مفتوح" مفقود، إشارات متضاربة

تلتقط هذه الاختبارات الأخطاء الحدودية، الحقول المفقودة، وسلوك النموذج الذي يحاول تعبئة المجهول.

اختبارات السيناريوهات لسير العمل (مسارات متعددة الخطوات، واعية بالزمن)

تفشل سير العمل عندما تصبح الحالة غير متسقة عبر الخطوات. تختبر اختبارات السيناريو الرحلات الحقيقية:

• اختبارات المسار: تقديم المطالبة → طلب مستندات → استلام المستندات → القرار
• حواف زمنية: "إذا لم يكن هناك رد خلال 7 أيام، أرسل تذكيرًا"، "إذا مرت 30 يومًا، أغلق الحالة"
• التفرع: العميل يصعّد، طُلب استثناء سياسة، اكتُشف حالة مكررة

الهدف التأكد من أن النموذج يحترم الحالة الحالية ولا يتخذ انتقالات غير مسموح بها.

بناء "مجموعة ذهبية" من الحالات الصحيحة

أنشئ مجموعة من أمثلة حقيقية مُجهّلة ومصادق عليها مع نتائج متفق عليها (ومبررات موجزة). احتفظ بها بإصدارات وراجعها عند تغيير السياسة. مجموعة ذهبية صغيرة (حتى 100–500 حالة) قوية لأنها تعكس الواقع الفوضوي—البيانات المفقودة، الصياغات غير العادية، القرارات الحدية.

المراقبة في الإنتاج (التقاط الانحراف قبل العملاء)

تابع توزيعات القرارات وإشارات الجودة عبر الزمن:

• الانحراف: معدلات القبول/الرفض تتغير دون تحديث سياسة
• قفزات في needs_review أو التحويل إلى البشر (غالبًا مشكلة في الموجه أو الاسترجاع أو البيانات العليا)
• مجموعات أخطاء حسب المنتج، المنطقة، أو فئة السياسة

اجعل المراقبة مصحوبة بآلية تراجع آمنة: احتفظ بحزمة الموجه/القواعد السابقة، فعّل خصائص الإصدار التجريبي، واستعد للتراجع بسرعة عندما تتراجع المقاييس. للاطلاع على لعبات التشغيل التشغيلية وتأمين الإصدار، راجع /blog/validation-strategies.

أين تتناسب Koder.ai في هذا الخط الزمني

إذا كنت تنفذ الأنماط أعلاه، فعادة ستبني نظامًا صغيرًا حول النموذج: تخزين الحالة، استدعاءات الأدوات، الاسترجاع، التحقق الشمولي، ومنسق سير العمل. Koder.ai طريقة عملية لنمذجة ونشر مساعد معتمد على سير العمل بسرعة: يمكنك وصف سير العمل في الدردشة، توليد تطبيق ويب يعمل (React) بالإضافة إلى خدمات خلفية (Go مع PostgreSQL)، والتكرار بأمان باستخدام لقطات واسترجاع.

هذا مهم لاستدلال قواعد الأعمال لأن "الحواجز" غالبًا ما تعيش في التطبيق، لا في الموجه:

• وضع التخطيط يساعدك على تصميم التدفق (الحالات، الانتقالات المسموح بها، مسارات التصعيد) قبل التنفيذ.
• الاستجابات المقيدة بالشَّمَلات يمكن فرضها على مستوى الـAPI، لذا تقبل فقط القرارات القابلة للتحليل.
• خطافات أدوات (قراءات DB، استرجاع السياسة، الحاسبات، تحديثات التذاكر) يمكن تنفيذها كنقاط نهاية صريحة، مما يجعل "جلب الدليل أولًا، ثم القرار" افتراضيًا.
• تصدير شفرة المصدر يمنعك من التعلّق بمجرد أن يصبح النموذج حرجًا للإنتاج.

حدود، استخدام آمن، ومتى تضع إنسانًا في الحلقة

يمكن لنماذج اللغات أن تكون جيدة بشكل مدهش في تطبيق السياسات اليومية، لكنها ليست محرك قواعد حتمي. عاملها كمساعد قرار يحتاج حواجز حماية، وليس كسلطة نهائية.

أين تكافح نماذج اللغات عادة

ثلاثة أوضاع فشل تظهر باستمرار في سير العمل الثقيل بالقواعد:

• الاستثناءات النادرة وحالات الحافة: إذا حدث استثناء مرة كل سنة، فقد يكون نادرًا في بيانات التدريب وسهل التغاضي عنه ما لم يُقدّم صراحة في الموجه أو يُسترجع من وثائق السياسة.
• السياقات الطويلة والقيود "المخبأة": عندما تكون التفاصيل الرئيسية مبعثرة عبر صفحات أو رسائل كثيرة، قد يبالغ النموذج في وزن النص الأحدث أو الأكثر وضوحًا ويقلل تطبيق القيود السابقة.
• الدقة العددية والحسابات الصارمة: الإجماليات، التقسيم النسبي، العتبات، وقواعد التقريب قد تنحرف. استخدم أدوات للعمليات الحسابية واطلب من النموذج الاستشهاد بالأرقام الدقيقة التي استخدمها.

متى تطلب مراجعة بشرية

أضف مراجعة إلزامية عندما:

• النتيجة عالية المخاطر (تحريك أموال، امتثال، سلامة، التزامات قانونية، ائتمان/أهلية العملاء).
• النموذج يظهر ثقة منخفضة (يطلب التخمين لمدخلات مفقودة، لا يجد أساسًا في السياسات، أو ينتج منطقًا متناقضًا).
• الحالة جديدة (منتج جديد، منطقة جديدة، سياسة تغيرت مؤخرًا) أو حساسة بشكل غير عادي.

مسارات التصعيد التي تُبقي الأمور متحركة

بدلًا من ترك النموذج "يخترع"، عرّف خطوات واضحة:

1. اطرح أسئلة توضيحية (تواريخ مفقودة، فئة العميل، الولاية القضائية، حالة الموافقة).
2. وجّه إلى وكيل مع الوقائع المستخرجة، القرار المقترح، والاستشهادات.
3. أنشئ تذكرة عندما تكون السياسة غامضة أو متضاربة، ليُصلح المصدر لاحقًا (ويُسترجع تلقائيًا لاحقًا).

إطار اعتماد بسيط

استخدم نماذج اللغات في سير العمل الثقيل بالقواعد عندما يمكنك الإجابة بـ"نعم" على معظم ما يلي:

• هل يمكننا تأصيل القرارات في نص سياسة معتمد أو بيانات نظام؟
• هل يمكننا تقييد المخرجات (شَّمَلات، إجراءات مسموح بها، استشهادات مطلوبة)؟
• هل يمكننا التحقق (فحوص، عتبات، اختبارات وحدة، أخذ عينات) قبل التنفيذ؟
• هل لدينا مسار تصعيد بشري للحالات الخطرة أو الغامضة؟

إن لم يكن كذلك، احتفظ بالـLLM في دور المسودة/المساعد حتى تتوفر تلك الضوابط.