একটি সাপোর্ট বট যা অ্যাকাউন্টের ব্যালেন্স বানিয়ে বলে, তা একটি ডিজিটাল ব্যাংকের জন্য কেবল অকেজো নয়, বরং বিপজ্জনক। আর্থিক আলোচনার ক্ষেত্রে সঠিক সংখ্যা, যাচাইকৃত প্রাপক এবং প্রতিটি দাবির জন্য একটি অডিট ট্রেইল থাকা প্রয়োজন। লার্জ ল্যাঙ্গুয়েজ মডেলগুলো কথোপকথনে পারদর্শী হলেও, তারা হ্যালুসিনেশন (hallucinate) করে। যখন একজন ব্যবহারকারী জিজ্ঞাসা করেন, “How much remain for my account?” তখন মডেলটিকে ডেটাবেস থেকে তথ্য নিতে হবে, কল্পনার সাহায্য নেওয়া চলবে না। ফাংশন কলিং (function calling) ঠিক এই বিষয়টিই নিশ্চিত করে এবং এটিই এই প্রজেক্টের মূল ভিত্তি।

Google-এর Gemma 4 ডেভেলপারদের একটি সক্ষম ৩১-বিলিয়ন প্যারামিটার মডেল প্রদান করে, যা জটিল নির্দেশনা অনুসরণ করতে পারে এবং আঞ্চলিক উপভাষাসহ স্বাভাবিকভাবে কথোপকথন চালিয়ে যেতে পারে। Google AI Studio-এর সাথে যুক্ত হয়ে এটি একটি দ্রুত প্রোটোটাইপিং পরিবেশে পরিণত হয়, যেখানে আপনি সার্ভার স্পর্শ করার আগেই টুল সংজ্ঞায়িত করতে পারেন, এজ কেস (edge cases) পরীক্ষা করতে পারেন এবং কার্যকরী JavaScript এক্সপোর্ট করতে পারেন। আমাদের লক্ষ্য হলো একটি ফিনটেক সাপোর্ট এজেন্ট তৈরি করা যা অ্যাকাউন্টের ব্যালেন্স চেক করতে পারে, লেনদেনের স্ট্যাটাস ট্র্যাক করতে পারে এবং বিল পরিশোধ করতে পারে। সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো, ব্যবহারকারী যদি নাইজেরিয়ান পিডজিনে (Nigerian Pidgin) কথা বলেন, তবে মডেলটিও সেই টোনে উত্তর দেবে, কিন্তু আর্থিক তথ্যের ক্ষেত্রে কখনোই কোনো কাল্পনিক তথ্য দেবে না।

কেন ফিন্যান্সিয়াল বটগুলোর জন্য ফাংশন কলিং গুরুত্বপূর্ণ

ফাংশন কলিং ছাড়া, একটি ল্যাঙ্গুয়েজ মডেল প্রতিটি প্রশ্নকে একটি সৃজনশীল লেখার অনুশীলন হিসেবে গণ্য করে। আপনি যদি ব্যালেন্স জানতে চান, তবে এটি তার ট্রেনিং ডেটার প্যাটার্ন থেকে একটি বিশ্বাসযোগ্য মনে হয় এমন সংখ্যা বানিয়ে বলতে পারে। যখন আসল অর্থের বিষয় জড়িত থাকে, তখন এই ধরনের ভুল গ্রহণযোগ্য নয়।

ফাংশন কলিং এই প্রবাহকে উল্টে দেয়। মডেলের কাজ ব্যালেন্স জানা নয়; এর কাজ হলো ব্যবহারকারীর উদ্দেশ্য (intent) শনাক্ত করা, সঠিক টুল নির্বাচন করা এবং প্যারামিটারগুলো বের করা। যখন একজন ব্যবহারকারী লেখেন “Check my balance,” তখন Gemma 4 একটি স্ট্রাকচার্ড JSON রিকোয়েস্ট প্রদান করে—যেমন account_id-সহ একটি get_balance কল। আপনার ব্যাকএন্ড সেই কলটি কোর ব্যাংকিং সিস্টেমের বিপরীতে কার্যকর করে, আসল সংখ্যাটি সংগ্রহ করে এবং তা কথোপকথনে ফিরিয়ে দেয়। কেবল তখনই মডেলটি মানুষের জন্য উপযোগী বাক্যটি তৈরি করে। প্রতিটি উত্তর একটি ব্যাকএন্ড টুল কল থেকে আসে। যেহেতু মডেলটি এক্সটার্নাল লজিক দ্বারা নিয়ন্ত্রিত, তাই হ্যালুসিনেশনগুলো API বাউন্ডারিতেই থেমে যায়।

এই পদ্ধতিটি একটি পরিষ্কার অডিট ট্রেইলও তৈরি করে। প্রতিটি টুল রিকোয়েস্ট এবং তার সংশ্লিষ্ট ফলাফল মেসেজ হিস্ট্রিতে লগ করা থাকে। রেগুলেটর এবং রিস্ক টিমগুলো ঠিক কখন ব্যালেন্স চেক করা হয়েছিল এবং ব্যবহারকারী কোন সংখ্যাটি পেয়েছিলেন তা পরীক্ষা করতে পারে।

Google AI Studio-তে এজেন্ট ডিজাইন করা

ওয়ার্কফ্লোটি Google AI Studio-র ভেতর থেকে শুরু হয়। gemma-4-31b-it সিলেক্ট করুন, যা কথোপকথন এবং নির্দেশনা অনুসরণের জন্য অপ্টিমাইজ করা একটি ইনস্ট্রাক্ট-টিউনড (instruct-tuned) ভেরিয়েন্ট।

এরপর, এমন সিস্টেম ইনস্ট্রাকশন লিখুন যা কঠোর সীমানা নির্ধারণ করে দেয়। একটি ডিজিটাল ব্যাংকের জন্য টোন হওয়া উচিত পেশাদার, সরাসরি এবং শান্ত। তবে ইনস্ট্রাকশনগুলো আরও সুনির্দিষ্ট হতে হবে। মডেলটিকে স্পষ্টভাবে বলে দিন যে এটি কখনোই অ্যাকাউন্টের ডেটা অনুমান করবে না, লেনদেনের স্ট্যাটাস নিয়ে ধারণা করবে না এবং টুল রেজাল্ট নিশ্চিত না করে কখনোই বিল পেমেন্ট সম্পন্ন করবে না। ব্যবহারকারী যদি নাইজেরিয়ান পিডজিনে লেখে, তবে মডেলকেও নাইজেরিয়ান পিডজিনে উত্তর দিতে হবে। ব্যবহারকারী যদি ইংরেজিতে চলে যায়, তবে মডেলও তা অনুসরণ করবে। সিস্টেম প্রম্পট হলো সেই জায়গা যেখানে আপনি সহজ ভাষায় বিশ্বাসযোগ্যতা এবং নিরাপত্তা নীতি (trust and safety policy) এনকোড করেন।

এরপর টুল স্কিমাগুলো (tool schemas) সংজ্ঞায়িত করুন। এগুলোকে মডেল এবং আপনার ব্যাকএন্ডের মধ্যে একটি চুক্তি হিসেবে ভাবুন। আপনার অন্তত তিনটি স্কিমা প্রয়োজন:

  1. get_balance
    Parameters: account_id (string, required)
    Returns: current balance and currency.

  2. get_transaction_status
    Parameters: transaction_reference (string, required)
    Returns: status such as pending, completed, or failed, plus a timestamp.

  3. pay_bill
    Parameters: biller_code (string, required), amount (number, required), account_pin (string, optional depending on your flow)
    Returns: confirmation reference or error message.

প্রতিটি স্কিমা একটি স্ট্যান্ডার্ড JSON ফরম্যাট ব্যবহার করে যা ফাংশনের নাম, বর্ণনা এবং প্যারামিটার প্রোপার্টি বর্ণনা করে। ডেসক্রিপশন ফিল্ডগুলো অত্যন্ত গুরুত্বপূর্ণ। এগুলো এমনভাবে লিখুন যাতে মডেল বুঝতে পারে কখন কোন টুলটি ব্যবহার করতে হবে। অস্পষ্ট বর্ণনা ভুল টুল নির্বাচনের দিকে নিয়ে যায়, তাই সুনির্দিষ্ট হোন: “Use get_balance when the user wants to know their current account balance. Do not use it for transaction history.”

ব্রাউজারে প্রোটোটাইপিং

একটি Express রুট লেখার আগেই, AI Studio-র চ্যাট প্যানেলের ভেতর পুরো কথোপকথনটি পরীক্ষা করে দেখুন। এটি ব্যাকএন্ডের পুনরায় কাজ করার অনেক সময় বাঁচিয়ে দেয়। নাইজেরিয়ান পিডজিনে একটি কুয়েরি লিখুন: “Wetin remain inside my account?” লক্ষ্য করুন Gemma 4 সঠিকভাবে get_balance কল করছে কি না, নাকি এটি ট্রেনিং ডেটা থেকে উত্তর দেওয়ার চেষ্টা করছে। যদি এটি প্যারামিটার ভুল করে—যেমন account_id-এর পরিবর্তে account_number ব্যবহার করে—তবে আপনি সেখানেই স্কিমা ডেসক্রিপশন ঠিক করে নিতে পারেন।

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