إن وجود بوت دعم يختلق أرصدة الحسابات ليس مجرد أمر عديم الفائدة في البنك الرقمي، بل هو أمر خطير. تتطلب المحادثات المالية أرقاماً دقيقة، ومستفيدين تم التحقق منهم، ومسار تدقيق لكل ادعاء. تتفوق النماذج اللغوية الكبيرة في المحادثة، لكنها تهلوس. عندما يسأل المستخدم: "كم تبقى في حسابي؟"، يجب على النموذج اللجوء إلى قاعدة بيانات، وليس إلى الخيال. هذا هو بالضبط ما يفرضه استدعاء الدوال (function calling)، وهو جوهر هذا المشروع.
يوفر نموذج Gemma 4 من Google للمطورين نموذجاً قوياً بـ 31 مليار معلمة (parameter) يمكنه اتباع تعليمات معقدة وإجراء حوار طبيعي، بما في ذلك اللهجات الإقليمية. وعند اقترانه بـ Google AI Studio، يصبح بيئة سريعة للنماذج الأولية حيث يمكنك تحديد الأدوات، واختبار الحالات الحدية، وتصدير كود JavaScript جاهز للعمل قبل أن تلمس الخادم. الهدف هنا هو إنشاء وكيل دعم للتكنولوجيا المالية (fintech) يتحقق من أرصدة الحسابات، ويتتبع حالة المعاملات، ويدفع الفواتير. والأهم من ذلك، أنه يستجيب بلغة البيجين النيجيرية (Nigerian Pidgin) عندما يفعل المستخدم ذلك، مما يطابق النبرة دون الارتجال في الحقائق المالية أبداً.
لماذا يهم استدعاء الدوال (Function Calling) لبوتات الخدمات المالية
بدون استدعاء الدوال، يعامل النموذج اللغوي كل سؤال كتمرين في الكتابة الإبداعية. اطلب منه الرصيد، فقد يخترع رقماً يبدو منطقياً مستمداً من الأنماط الموجودة في بيانات التدريب الخاصة به. هذا النوع من الفشل غير مقبول عندما يتعلق الأمر بأموال حقيقية.
يعكس استدعاء الدوال هذا التدفق. وظيفة النموذج ليست معرفة الرصيد، بل وظيفته هي التعرف على القصد، واختيار الأداة الصحيحة، واستخراج المعاملات (parameters). عندما يكتب المستخدم "تحقق من رصيدي"، يصدر Gemma 4 طلباً مهيكلاً بتنسيق JSON — شيء يشبه استدعاء get_balance مع account_id. تقوم الواجهة الخلفية (backend) الخاصة بك بتنفيذ هذا الاستدعاء مقابل النظام المصرفي الأساسي، وتحصل على الرقم الحقيقي، ثم تغذيه مرة أخرى في المحادثة. عندها فقط يقوم النموذج بتوليد الجملة الموجهة للإنسان. كل إجابة تأتي من استدعاء أداة إلى الواجهة الخلفية. ولأن النموذج محكوم بمنطق خارجي، فإن الهلوسة تتوقف عند حدود واجهة برمجة التطبيقات (API).
يخلق هذا النمط أيضاً مسارات تدقيق واضحة. يتم تسجيل كل طلب أداة والنتيجة المقابلة له في سجل الرسائل. يمكن للمنظمين وفرق المخاطر فحص متى تم التحقق من الرصيد بالضبط وما هو الرقم الذي تلقاه المستخدم.
تصميم الوكيل في Google AI Studio
يبدأ سير العمل داخل Google AI Studio. اختر gemma-4-31b-it ، وهو الإصدار المضبوط للتعليمات (instruct-tuned) والمحسن للحوار واتباع التعليمات.
بعد ذلك، اكتب تعليمات النظام التي تضع حدوداً صارمة. بالنسبة للبنك الرقمي، يجب أن تكون النبرة مهنية ومباشرة وهادئة. ولكن يجب أن تذهب التعليمات إلى أبعد من ذلك. أخبر النموذج صراحة أنه لا يقوم أبداً بتقدير بيانات الحساب، ولا يفترض حالة المعاملة، ولا يكمل دفع الفاتورة دون تأكيد نتيجة الأداة. إذا كتب المستخدم بلغة البيجين النيجيرية، يجب أن يرد النموذج بلغة البيجين النيجيرية. وإذا انتقل المستخدم إلى اللغة الإنجليزية، يتبعه النموذج. مطالبة النظام (system prompt) هي المكان الذي ترمز فيه سياسة الثقة والسلامة بلغة بسيطة.
ثم حدد مخططات الأدوات (tool schemas). فكر في هذه المخططات كعقود بين النموذج والواجهة الخلفية الخاصة بك. تحتاج إلى ثلاث أدوات على الأقل:
get_balance
المعاملات:account_id(string، مطلوب)
النتيجة: الرصيد الحالي والعملة.get_transaction_status
المعاملات:transaction_reference(string، مطلوب)
النتيجة: الحالة مثل "قيد الانتظار" أو "مكتملة" أو "فاشلة"، بالإضافة إلى الطابع الزمني.pay_bill
المعاملات:biller_code(string، مطلوب)،amount(number، مطلوب)،account_pin(string، اختياري حسب تدفق العمل لديك)
النتيجة: مرجع التأكيد أو رسالة خطأ.
يستخدم كل مخطط تنسيق JSON قياسياً يصف اسم الدالة، والوصف، وخصائص المعاملات. حقول الوصف مهمة للغاية. اكتبها بحيث يفهم النموذج متى يستدعي كل أداة. تؤدي الأوصاف الغامضة إلى اختيار الأداة الخاطئة، لذا كن محدداً: "استخدم get_balance عندما يريد المستخدم معرفة رصيد حسابه الحالي. لا تستخدمها لسجل المعاملات".
بناء النموذج الأولي في المتصفح
قبل كتابة مسار Express واحد، اختبر تدفق المحادثة بالكامل داخل لوحة الدردشة في AI Studio. هذا يوفر أياماً من إعادة العمل في الواجهة الخلفية. اكتب استعلاماً بلغة البيجين النيجيرية: “Wetin remain inside my account?” راقب ما إذا كان Gemma 4 سيصدر استدعاء get_balance بشكل صحيح أم أنه سيحاول الإجابة من بيانات التدريب. إذا أخطأ في المعاملات — ربما باستخدام account_number بدلاً من account_id — فقم بإصلاح وصف المخطط هناك مباشرة.
Test the failure modes too. Ask for a transaction status without providing a reference number. A well-instructed model should either ask the user for the missing parameter or call the tool with what it has and let the backend return a validation error. You want to see these behaviors in the sandbox, not in production.
Once the prompts and schemas behave correctly, export the JavaScript code. AI Studio generates a clean snippet that structures the API request with your system prompt, user message, and tool definitions. This becomes the foundation of your backend logic.
Wiring Up the Express Backend
Take the exported code and drop it into an Express application. The architecture is straightforward, but the execution loop is the critical piece.
Set up a POST endpoint—perhaps /chat—that accepts the user’s message and any session history. Forward these to the Gemma 4 endpoint, which you can hit via an OpenAI-compatible API or Google’s own inference endpoint depending on your hosting choice.
The response from the model falls into one of two categories. Either it is a final text message, or it contains a tool_call requesting data. When you receive a tool call, execute the corresponding function against your backend. Query the database for the balance. Hit the payment processor for the bill status. Append the tool result to the conversation history as a new message with the role tool, and send the entire updated array back to Gemma 4.
Repeat this loop until the model returns a final text answer. That answer will be grounded in the real data you supplied. Express makes this easy to coordinate because each pass through the loop is just another HTTP request, and you can async/await the tool execution cleanly.
During early development, back these tool calls with mock data. A simple JavaScript object mapping sample account IDs to balances is enough to prove the loop works. The point is to validate the interaction pattern before integrating with brittle third-party banking APIs.
From Prototype to Production
A working prototype is not production banking infrastructure, but the path from one to the other is clear.
Replace the mock data with real core banking APIs. Connect your get_balance tool to the ledger system over REST or gRPC. Hook pay_bill into your actual payment switch. When you do this, you do not need to change the model or the conversation logic; you only swap the implementation of the tool handlers.
Add Redis for session management. Conversational state in banking is sensitive and regulated. You need to store message histories securely, expire them after a set timeout, and ensure that a user’s session cannot leak across requests. Redis handles this with TTL policies and fast key lookups.
When traffic grows, moveInference to vLLM. AI Studio is excellent for prototyping, but self-hosted inference with vLLM on GPU clusters gives you control over latency, batching, and cost at scale. Gemma 4 runs efficiently under vLLM, and the tool-calling behavior remains identical.
The Real Takeaway
Building a trustworthy fintech agent is less about model size and more about architectural constraints. Gemma 4 provides enough reasoning power to parse code-switched Nigerian Pidgin and route complex intents, but the safety comes from the tool loop. Every balance is fetched live. Every bill payment is confirmed by an external system. Nothing is invented.
Start in the browser with AI Studio, harden the logic in an Express loop, and swap in real banking infrastructure once the conversation flows are bulletproof. That is how you ship a bot people can actually trust with their money.
Source: Building a Full Gemma 4 Google AI Studio Project: A Fintech Support Agent
Optional learning community: GyaanSetu AI on Telegram