Un bot de support qui invente des soldes de compte n'est pas seulement inutile dans une banque numérique. Il est dangereux. Les conversations financières exigent des chiffres exacts, des bénéficiaires vérifiés et une piste d'audit pour chaque affirmation. Les grands modèles de langage excellent dans la conversation, mais ils hallucinent. Lorsqu'un utilisateur demande : « Combien reste-t-il sur mon compte ? », le modèle doit solliciter une base de données, et non son imagination. C'est précisément ce que l'appel de fonction (function calling) impose, et c'est le cœur de cette réalisation.
Le modèle Gemma 4 de Google offre aux développeurs un modèle performant de 31 milliards de paramètres capable de suivre des instructions complexes et de mener un dialogue naturel, y compris dans des dialectes régionaux. Associé à Google AI Studio, il devient un environnement de prototypage rapide où vous pouvez définir des outils, tester des cas limites et exporter du JavaScript fonctionnel avant même de toucher à un serveur. L'objectif ici est de créer un agent de support fintech qui vérifie les soldes de compte, suit le statut des transactions et paie des factures. Point crucial : il répond en pidgin nigérian lorsque l'utilisateur le fait, adoptant le même ton sans jamais improviser de faits financiers.
Pourquoi l'appel de fonction est crucial pour les bots financiers
Sans l'appel de fonction, un modèle de langage traite chaque question comme un exercice d'écriture créative. Demandez-lui un solde et il pourrait inventer un chiffre plausible tiré des schémas de ses données d'entraînement. Ce mode de défaillance est inacceptable lorsqu'il s'agit d'argent réel.
L'appel de fonction inverse le flux. Le rôle du modèle n'est pas de connaître le solde. Son rôle est de reconnaître l'intention, de choisir le bon outil et d'extraire les paramètres. Lorsqu'un utilisateur écrit « Vérifie mon solde », Gemma 4 émet une requête JSON structurée — quelque chose comme un appel à get_balance avec un account_id. Votre backend exécute cet appel auprès du système bancaire central, récupère le chiffre réel et le réinjecte dans la conversation. Ce n'est qu'à ce moment-là que le modèle génère la phrase destinée à l'humain. Chaque réponse provient d'un appel d'outil vers un backend. Comme le modèle est encadré par une logique externe, les hallucinations s'arrêtent à la limite de l'API.
Ce modèle crée également des pistes d'audit claires. Chaque requête d'outil et son résultat correspondant sont enregistrés dans l'historique des messages. Les régulateurs et les équipes de gestion des risques peuvent inspecter exactement quand un solde a été vérifié et quel chiffre l'utilisateur a reçu.
Concevoir l'agent dans Google AI Studio
Le flux de travail commence à l'intérieur de Google AI Studio. Sélectionnez gemma-4-31b-it, la variante optimisée pour l'instruction (instruct-tuned) pour le dialogue et le suivi d'instructions.
Ensuite, rédigez des instructions système qui fixent des limites strictes. Pour une banque numérique, le ton doit être professionnel, direct et calme. Mais les instructions doivent aller plus loin. Dites explicitement au modèle qu'il ne doit jamais estimer les données de compte, jamais supposer un statut de transaction et jamais effectuer le paiement d'une facture sans confirmer le résultat de l'outil. Si l'utilisateur écrit en pidgin nigérian, le modèle doit répondre en pidgin nigérian. Si l'utilisateur passe à l'anglais, le modèle suit. Le prompt système est l'endroit où vous encodez la politique de confiance et de sécurité en langage clair.
Définissez ensuite les schémas d'outils (tool schemas). Considérez-les comme des contrats entre le modèle et votre backend. Vous en avez besoin d'au moins trois :
get_balance
Paramètres :account_id(string, requis)
Retourne : le solde actuel et la devise.get_transaction_status
Paramètres :transaction_reference(string, requis)
Retourne : le statut tel que "en attente", "terminé" ou "échoué", ainsi qu'un horodatage.pay_bill
Paramètres :biller_code(string, requis),amount(number, requis),account_pin(string, optionnel selon votre flux)
Retourne : une référence de confirmation ou un message d'erreur.
Chaque schéma utilise un format JSON standard décrivant le nom de la fonction, sa description et les propriétés des paramètres. Les champs de description sont d'une importance capitale. Rédigez-les de manière à ce que le modèle comprenne quand invoquer chaque outil. Des descriptions ambiguës entraînent une mauvaise sélection d'outils, alors soyez spécifique : « Utilisez get_balance lorsque l'utilisateur souhaite connaître le solde actuel de son compte. Ne l'utilisez pas pour l'historique des transactions. »
Prototypage dans le navigateur
Avant d'écrire la moindre route Express, testez l'intégralité du flux de conversation dans le panneau de chat d'AI Studio. Cela vous évitera des jours de retravail sur le backend. Tapez une requête en pidgin nigérian : « Wetin remain inside my account ? ». Observez si Gemma 4 émet correctement un appel get_balance ou s'il tente de répondre à partir de ses données d'entraînement. S'il se trompe dans les paramètres — par exemple en utilisant account_number au lieu de account_id — vous pouvez corriger la description du schéma immédiatement.
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