لماذا يجب على وكلاء التمويل استدعاء الأدوات لا إجراء الحسابات بأنفسهم

اطلب من نموذج لغوي كبير أن يجمع رقمين من تسع خانات، وغالبًا ما سيعيد لك ناتجًا يبدو صحيحًا تمامًا لكنه يخطئ ببضعة آلاف. الأرقام معقولة، والقيمة في حدود المتوقع، غير أن الجواب خاطئ. هذا السلوك وحده هو السبب في انهيار معظم عروض «الذكاء الاصطناعي للتمويل» في اللحظة التي يتحقق فيها المراقب المالي من الحساب.

وإليك الآلية المُحرجة وراء ذلك. النموذج اللغوي لا يُجري عمليات حسابية، بل يتنبأ بالرمز التالي. حين تطلب منه طرح 9,335,402 من 14,820,116، فهو لا يطرح؛ بل يولّد تسلسل الأرقام الأرجح إحصائيًا أن يأتي بعد مُدخلك، استنادًا إلى كل ما استوعبه أثناء التدريب. أما المجاميع الصغيرة الشائعة فقد حفظ أنماطها فعليًا فيصيب فيها. لكن مع الأرقام الطويلة غير المنتظمة التي يزخر بها دفتر الأستاذ العام الحقيقي، فإنه يخمّن شكلًا. أحيانًا يصيب التخمين، ولا سبيل لك إلى معرفة متى ذلك من المُخرج وحده، لأن الرقم الخاطئ الواثق يبدو مطابقًا تمامًا للرقم الصحيح الواثق.

الرقم يبدو صحيحًا، وهنا تكمن المشكلة

هذه المشكلة أخطر من عيوب البرمجيات المعتادة، لأن نمط الفشل هنا متخفٍّ. المعادلة المعطوبة في جدول البيانات تُظهر عادةً #REF! أو إجماليًا مستحيلًا بشكل صارخ. أما النموذج اللغوي فيُنتج رقمًا يستقر بكل ارتياح داخل النطاق الذي يتوقعه المدير المالي. الإيرادات التي ينبغي أن تكون 47.3 مليون تعود 46.9 مليون. هامش الربح الإجمالي الذي يجب أن يساوي 62% يعود 64%. لا شيء يدق ناقوس الخطر. ينجو الخطأ من المراجعة لسبب بالغ الدقة: لأنه وُلِّد ليبدو كأنه الحقيقة.

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

ولا يعني أيٌّ من ذلك أن النموذج عديم الفائدة، بل يعني أنك طلبت منه الشيء الوحيد الذي يعجز بنيويًا عن ضمانه.

الاستدلال في النموذج، والحساب في الطبقة

الحل ليس مُدخلًا أفضل ولا نموذجًا أكبر، بل تقسيمًا للعمل.

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

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

وبعبارة صريحة: على الوكيل أن يستدل في ما الذي يجب حسابه، ثم يستدعي شيئًا آخر ليحسبه فعلًا. حين يحسب الوكيل هامشًا في «رأسه» فأنت تأتمن توزيعًا احتماليًا على حساباتك المُدققة. وحين يستدعي أداة فأنت تأتمن الحساب الرياضي نفسه.

لماذا يظل استدعاء الأداة بحاجة إلى نموذج مُسوّى تحته

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

لذا يجب أن تعمل الأدوات على نموذج واحد مُسوّى، أي نموذج مالي واحد يتطابق مع دفتر الأستاذ، حيث لكل رقم مصدر معلوم، والمُدخلات متّسقة فيما بينها مسبقًا. هذا هو الجزء الذي تعتبره Rexfin الأساس. نربط منصات المحاسبة والبيانات المالية لديك (QuickBooks وXero وNetSuite وSage وSAP وOracle أو مستودع بيانات) أو القوائم المرفوعة، ونبني نموذجًا واحدًا مُسوّى يتطابق مع دفتر الأستاذ، ثم نُتيح فوقه أدوات حساب حتمية. الوكيل يستدل؛ والمحرك الحتمي يحسب؛ وكل مُخرج يعود أثره إلى المصدر.

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

ماذا يجني المدير المالي المتشكك من هذا

ثلاثة أمور، بشكل ملموس.

الأول، قابلية إعادة التشغيل. السؤال نفسه، إن طُرح مرتين، يعيد الرقم نفسه، لأن الحساب جرى في شيفرة لا في مُعاينٍ احتمالي. يمكنك إثبات رقم بالطريقة نفسها التي تثبت بها معادلة جدول بيانات: بإعادة تشغيلها.

الثاني، قابلية التتبع. ولأن الحساب جرى على نموذج مُسوّى، فإن كل مُخرج يشير إلى صفوف المصدر التي أنتجته. والمدقق الذي يسأل «من أين جاء هذا» يحصل على سلسلة أصل، لا على هزّة كتفين.

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

الخلاصة

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

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