جعل استدعاء الدوال (function calling) موثوقًا في سير العمل المالي

النموذج الذي يستدعي الأداة الخاطئة بوسائط خاطئة هو حادث إنتاجي، لا مجرد إجابة رديئة. تجعل استدعاء الدوال (function calling) موثوقًا في المجال المالي بأن تعامل كل أداة بوصفها عقدًا ذا أنواع محددة (typed contract)، وتتحقق من الوسائط في مقابل المخطط (schema) وقواعد عملك معًا قبل التنفيذ، وتُبقي مجموعة الأدوات المكشوفة صغيرة ولا لبس فيها، وتقيس دقة الاستدعاء على مجموعة تقييم (eval set) ثابتة بالطريقة نفسها التي تقيس بها نموذجًا.

معظم الفرق تُنجح العرض التوضيحي (demo) وتفترض أن الجزء الصعب قد انتهى. العرض ينجح لأن المدخل كان نظيفًا وقائمة الأدوات كانت قصيرة. أما الحادث فيقع بعد ثلاثة أسابيع، عند إقفال الربع السنوي، حين يستدعي وكيل تسوية (reconciliation agent) الدالة post_adjustment بدلًا من stage_adjustment لأن كلا الوصفين يذكر كلمة “adjustment” فخمّن النموذج. لم يكتب أحد جملة خاطئة. لكن قيدًا محاسبيًا دخل دفتر الأستاذ (ledger) كان ينبغي أن ينتظر المراجعة.

أنماط الفشل مملّة، وهذا بيت القصيد

يفشل استدعاء الدوال في سير العمل المالي بعدد صغير من الطرق المتوقعة، ولا يشبه أيٌّ منها قصص الهلوسة (hallucination) التي يقلق الناس بشأنها.

• الأداة الصحيحة، الوسيط الخاطئ. يستدعي النموذج get_positions لكنه يمرّر as_of بتاريخ اليوم بينما احتاج سير العمل إلى يوم العمل السابق. الاستدعاء ينجح. والرقم خاطئ. هذا خلل في الصحة عند نقطة زمنية محددة (point-in-time correctness) متنكرٌ في زيّ استجابة API ناجحة.
• الأداة الخاطئة، باسم معقول. أداتان بوصفين متداخلين، فيختار النموذج تلك التي تقرأ أقرب إلى الطلب. تصادمات التسمية (naming collisions) تسبّب إطلاقات خاطئة أكثر مما تسبّبه إخفاقات الاستدلال.
• سليمة الصياغة، خارجة عن السياسة. الوسائط تجتاز التحقق في مقابل مخطط JSON ومع ذلك تخالف قاعدة لا يشفّرها المخطط: تحويل يتجاوز حدًّا معيّنًا، أو طرف مقابل (counterparty) على قائمة مقيّدة، أو تاريخ خارج الفترة المفتوحة.
• التحويل الصامت للنوع (silent coercion). يُصدر النموذج القيمة "1,250.00" فيحلّلها مكوّن لاحق على أنها 1 أو 1250 بحسب الإعدادات المحلية (locale). التحويل من نصّ إلى رقم عند حدود الأداة هو المكان الذي يتغيّر فيه المال بهدوء بثلاث مراتب عشرية.

سبب سرد هذه الأنماط أن لكلٍّ منها ضابطًا محددًا. لا تُصلحها بمطالبة (prompt) أفضل. تُصلحها ببنية حول الاستدعاء.

عامل كل أداة كعقد ذي أنواع محددة، ثم تحقق مرتين

ابدأ بجعل سطح الوسائط ضيقًا بقدر ما تسمح به المهمة. إن كانت أداة تسترجع تقييمًا (valuation)، فينبغي أن تكون وسائطها معرّف الأداة المالية (instrument identifier) وطابعًا زمنيًا محلولًا عند نقطة زمنية محددة، لا استعلامًا نصيًا حرًّا يتعين على النموذج تركيبه. كل درجة حرية تمنحها للنموذج هي درجة حرية يمكن أن يخطئ فيها. التعدادات (enumerations) تتفوّق على النصوص الحرة. فمجموعة مغلقة من قيم report_period يختار منها النموذج لا يمكن أن تنحرف كما ينحرف نصّ تاريخ يبنيه بنفسه.

ثم تحقق على طبقتين، لأنهما تلتقطان أشياء مختلفة.

• التحقق البنيوي (structural validation). يجب أن تطابق الوسائط مخطط JSON: الأنواع، والحقول المطلوبة، والصيغ، والانتماء إلى التعداد. هذا رخيص وحتمي، ويرفض الاستدعاءات المشوّهة قبل أن تصل إلى نظام له كلفة. ارفض وأعِد الخطأ إلى النموذج ليعيد المحاولة والتصحيح حاضر في سياقه.
• التحقق الدلالي (semantic validation). يجب أن تُحقق الوسائط قواعد العمل التي لا يستطيع المخطط التعبير عنها. هل تاريخ as_of داخل فترة محاسبية مفتوحة؟ هل جرى حلّ الكيان (entity resolution) إلى طرف مقابل واحد لا لبس فيه بدلًا من مطابقة ضبابية عبر ثلاث تهجئات؟ هل المبلغ ضمن صلاحية من بادر بالطلب؟ هذه الفحوص هي المكان الذي يُفرض فيه فعليًا حلّ الكيان والصحة عند نقطة زمنية محددة.

إن الوسيط سليم الصياغة الذي يفشل في التحقق الدلالي هو الحالة الخطرة، لأن المخطط قال “نعم”. أبقِ هاتين الطبقتين منفصلتين في شفرتك كي تبقى الطبقة الدلالية قابلة للقراءة والمراجعة من قِبَل شخص من جانب الضوابط (controls) لا يقرأ تعريفات أنواعك.

قاعدة أخرى نلتزم بها: الأدوات المُعدِّلة للحالة (mutating tools) والأدوات القارئة تعيش في طبقات مختلفة. القراءة التي تعيد الرقم الخاطئ خللٌ تلتقطه لاحقًا. أما الكتابة التي تُرحّل قيدًا أو تُحوّل مالًا أو تعتمد فتترك أثرًا. كل ما يغيّر الحالة ينبغي أن يستلزم خطوة تأكيد صريحة ومُتحقَّقًا منها، ويجب ألا يكون قابلًا للوصول عبر مسار الاستدعاء نفسه غير المحروس الذي يستخدمه استعلام بسيط.

أبقِ مجموعة الأدوات صغيرة، وأزِل اللبس عن الباقين

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

• وجّه أولًا، ثم اعرض حفنة. صنّف الطلب إلى سير عمل، واكشف فقط عن الأدوات التي يحتاجها ذلك السير. وكيل التسوية لا يحتاج إلى رؤية أدوات الإعداد الأولي (onboarding).
• اكتب أوصافًا ترسم التباين بين الأدوات. إن كان لديك stage_adjustment وpost_adjustment، فينبغي أن يقول وصف كلٍّ منهما ماذا تفعل الأخرى ومتى لا تلجأ إليها. النموذج يزيل اللبس بناءً على النص الذي تعطيه إياه.
• فضّل أداة واحدة ذات وسائط قابلة للتخصيص (parameterized) على خمس أدوات شبه مكرّرة حين يكون الفرق وسيطًا لا قدرة. خمس أدوات لا تختلف إلا بنوع التقرير تدعو إلى أخطاء اختيار؛ أما أداة واحدة بتعداد report_type فلا.

قِس دقة الاستدعاء كما تقيس نموذجًا

لن تُطلق مصنّفًا (classifier) دون مجموعة تقييم. ونظام استدعاء الدوال هو مصنّف على فضاء أدواتك بالإضافة إلى مولّد وسائط، وهو يستحق الانضباط نفسه.

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

شغّل هذا مع كل تغيير في النموذج، وكل تغيير في المطالبة، وكل إضافة أداة. راقب الانحراف (drift) حين يحدّث مزوّد نموذجًا من تحتك، لأن سلوك اختيار الأداة يتبدّل بطرق تجتاز اختبار الدخان (smoke test) وتفشل في حالة الفترة المغلقة لديك. احتفظ بميزانية للإيجابيات الكاذبة (false-positive budget) للأدوات المُعدِّلة للحالة والتزم بها. الغاية كلها من المعالجة المباشرة الشاملة (straight-through processing) هي أن تُوجَّه الاستثناءات إلى إنسان، ولا يمكنك معرفة معدّل استثناءاتك دون قياس الاستدعاءات التي أنتجته.

ومسار التدقيق (audit trail) ينبثق من هذا طبيعيًا حين تفعله بشكل صحيح. كل استدعاء يحمل وسائطه المحلولة، ونتائج التحقق من كلتا الطبقتين، والحصيلة. وحين يسأل أحدهم بعد ستة أشهر عن سبب ترحيل تسوية يوم ثلاثاء، يكون التسلسل (lineage) حاضرًا بالفعل للقراءة.