یک بات پشتیبان که موجودی حسابها را از خودش در میآورد، در یک بانک دیجیتال فقط بیاستفاده نیست، بلکه خطرناک است. گفتگوهای مالی نیازمند اعداد دقیق، گیرندگان تایید شده و ردپای حسابرسی (audit trail) برای هر ادعا هستند. مدلهای زبانی بزرگ در گفتگو عالی هستند، اما دچار توهم (hallucinate) میشوند. وقتی کاربری میپرسد «چقدر در حساب من باقی مانده است؟»، مدل باید به یک پایگاه داده مراجعه کند، نه به تخیل خود. این دقیقاً همان چیزی است که فراخوانی تابع (function calling) آن را اعمال میکند و هسته اصلی این پروژه است.
مدل Gemma 4 گوگل، یک مدل توانمند با ۳۱ میلیارد پارامتر در اختیار توسعهدهندگان قرار میدهد که میتواند دستورالعملهای پیچیده را دنبال کند و گفتگوهای طبیعی، حتی با گویشهای منطقهای، داشته باشد. این مدل در ترکیب با Google AI Studio، به یک محیط نمونهسازی سریع تبدیل میشود که در آن میتوانید ابزارها را تعریف کنید، موارد خاص (edge cases) را آزمایش کنید و قبل از کار با سرور، کدهای JavaScript آماده را خروجی بگیرید. هدف در اینجا ساخت یک عامل پشتیبان فینتک است که موجودی حساب را چک کند، وضعیت تراکنشها را پیگیری کند و قبضها را پرداخت نماید. نکته حیاتی این است که اگر کاربر به زبان Pidgin نیجریهای صحبت کند، مدل نیز با همان لحن پاسخ میدهد، بدون اینکه هرگز در مورد واقعیتهای مالی از خود چیزی بسازد.
چرا فراخوانی تابع برای باتهای مالی اهمیت دارد
بدون فراخوانی تابع، یک مدل زبانی با هر سوال مانند یک تمرین نویسندگی خلاق برخورد میکند. اگر از آن موجودی بخواهید، ممکن است عددی با ظاهر باورپذیر را از الگوهای موجود در دادههای آموزشی خود ابداع کند. این نوع خطا زمانی که پول واقعی در میان باشد، غیرقابل قبول است.
فراخوانی تابع جریان کار را معکوس میکند. وظیفه مدل دانستن موجودی نیست؛ وظیفه آن تشخیص قصد کاربر (intent)، انتخاب ابزار صحیح و استخراج پارامترها است. وقتی کاربر مینویسد «موجودی من را چک کن»، Gemma 4 یک درخواست JSON ساختاریافته صادر میکند—چیزی شبیه به فراخوانی get_balance با یک account_id. بکاند (backend) شما آن فراخوانی را در سیستم بانکی اصلی اجرا میکند، رقم واقعی را دریافت میکند و آن را به گفتگو بازمیگرداند. تنها در این مرحله است که مدل جمله قابل فهم برای انسان را تولید میکند. هر پاسخ از طریق فراخوانی یک ابزار به سمت بکاند حاصل میشود. از آنجایی که مدل توسط منطق خارجی محدود شده است، توهمات در مرز API متوقف میشوند.
این الگو همچنین ردپای حسابرسی شفافی ایجاد میکند. هر درخواست ابزار و نتیجه مربوط به آن در تاریخچه پیامها ثبت میشود. نهادهای نظارتی و تیمهای مدیریت ریسک میتوانند دقیقاً بررسی کنند که موجودی چه زمانی چک شده و کاربر چه عددی را دریافت کرده است.
طراحی عامل در Google AI Studio
گردش کار از داخل Google AI Studio شروع میشود. مدل gemma-4-31b-it را انتخاب کنید؛ این نسخه instruct-tuned است که برای گفتگو و دنبال کردن دستورالعملها بهینه شده است.
سپس، دستورالعملهای سیستمی (system instructions) بنویسید که مرزهای مشخصی تعیین کنند. برای یک بانک دیجیتال، لحن باید حرفهای، مستقیم و آرام باشد. اما دستورالعملها باید فراتر از این بروند. صراحتاً به مدل بگویید که هرگز دادههای حساب را تخمین نزند، هرگز وضعیت تراکنش را حدس نزند و هرگز بدون تأیید نتیجه ابزار، پرداخت قبض را انجام ندهد. اگر کاربر به زبان Pidgin نیجریهای بنویسد، مدل باید به Pidgin نیجریهای پاسخ دهد. اگر کاربر به انگلیسی تغییر زبان داد، مدل نیز پیروی میکند. سیستم پرامپت (system prompt) جایی است که شما سیاستهای اعتماد و ایمنی را به زبان ساده کدگذاری میکنید.
سپس طرحوارههای ابزار (tool schemas) را تعریف کنید. اینها را به عنوان قراردادهایی بین مدل و بکاند خود در نظر بگیرید. شما حداقل به سه مورد نیاز دارید:
get_balance
پارامترها:account_id(رشته، الزامی)
خروجی: موجودی فعلی و واحد پول.get_transaction_status
پارامترها:transaction_reference(رشته، الزامی)
خروجی: وضعیتی مانند در انتظار (pending)، تکمیل شده (completed) یا ناموفق (failed)، به همراه برچسب زمانی (timestamp).pay_bill
پارامترها:biller_code(رشته، الزامی)،amount(عدد، الزامی)،account_pin(رشته، اختیاری بسته به جریان کاری شما)
خروجی: مرجع تأییدیه یا پیام خطا.
هر طرحواره از یک فرمت استاندارد JSON برای توصیف نام تابع، توضیحات و ویژگیهای پارامترها استفاده میکند. فیلدهای توضیحات (description) اهمیت بسیار زیادی دارند. آنها را طوری بنویسید که مدل بفهمد چه زمانی باید هر ابزار را فراخوانی کند. توضیحات مبهم منجر به انتخاب ابزار اشتباه میشود، بنابراین دقیق باشید: «زمانی از get_balance استفاده کنید که کاربر میخواهد از موجودی فعلی حساب خود مطلع شود. از آن برای تاریخچه تراکنشها استفاده نکنید.»
نمونهسازی در مرورگر
قبل از اینکه حتی یک مسیر Express بنویسید، کل جریان گفتگو را در پنل چت AI Studio آزمایش کنید. این کار باعث صرفهجویی در روزها بازنویسی بکاند میشود. یک پرسش به زبان Pidgin نیجریهای تایپ کنید: “Wetin remain inside my account?” مشاهده کنید که آیا Gemma 4 به درستی یک فراخوانی get_balance صادر میکند یا اینکه سعی میکند از دادههای آموزشی خود پاسخ دهد. اگر پارامترها را اشتباه وارد کرد—مثلاً به جای account_id از account_number استفاده کرد—همانجا توضیحات طرحواره را اصلاح کنید.
حالتهای شکست را نیز آزمایش کنید. وضعیت یک تراکنش را بدون ارائه شماره مرجع درخواست کنید. یک مدل که به خوبی آموزش دیده باشد، یا باید پارامتر مفقود را از کاربر بخواهد یا ابزار را با آنچه در اختیار دارد فراخوانی کند و اجازه دهد بکاند یک خطای اعتبارسنجی برگرداند. شما میخواهید این رفتارها را در محیط sandbox مشاهده کنید، نه در محیط production.
زمانی که پرامپتها و طرحوارهها (schemas) به درستی عمل کردند، کد JavaScript را خروجی بگیرید. AI Studio یک قطعه کد (snippet) تمیز تولید میکند که درخواست API را با پرامپت سیستم، پیام کاربر و تعاریف ابزار ساختاردهی میکند. این بخش به پایه و اساس منطق بکاند شما تبدیل میشود.
اتصال به بکاند Express
کد خروجی را بردارید و در یک اپلیکیشن Express قرار دهید. معماری ساده است، اما حلقه اجرا (execution loop) بخش حیاتی کار است.
یک نقطه پایانی (endpoint) از نوع POST — مثلاً /chat — ایجاد کنید که پیام کاربر و هرگونه تاریخچه نشست (session history) را بپذیرد. این موارد را به نقطه پایانی Gemma 4 ارسال کنید؛ بسته به انتخاب خود برای میزبانی، میتوانید از طریق یک API سازگار با OpenAI یا نقطه پایانی استنتاج (inference endpoint) خود گوگل به آن متصل شوید.
پاسخ مدل در یکی از دو دسته قرار میگیرد: یا یک پیام متنی نهایی است، یا حاوی یک tool_call برای درخواست داده است. وقتی یک فراخوانی ابزار (tool call) دریافت کردید، تابع مربوطه را در بکاند خود اجرا کنید. برای دریافت موجودی، از پایگاه داده پرسوجو (query) کنید. برای وضعیت صورتحساب، به پردازشگر پرداخت درخواست بفرستید. نتیجه ابزار را به عنوان یک پیام جدید با نقش tool به تاریخچه گفتگو اضافه کنید و کل آرایه بهروزرسانیشده را دوباره به Gemma 4 بفرستید.
این حلقه را تا زمانی که مدل یک پاسخ متنی نهایی برگرداند، تکرار کنید. آن پاسخ بر اساس دادههای واقعی که ارائه کردهاید خواهد بود. Express هماهنگی این کار را آسان میکند، زیرا هر بار عبور از حلقه، صرفاً یک درخواست HTTP دیگر است و میتوانید اجرای ابزار را به شکلی تمیز با async/await مدیریت کنید.
در مراحل اولیه توسعه، این فراخوانیهای ابزار را با دادههای ساختگی (mock data) پشتیبانی کنید. یک شیء JavaScript ساده که شناسههای نمونه حساب را به موجودیها نگاشت میکند، برای اثبات کارکرد حلقه کافی است. هدف این است که الگوی تعامل را قبل از ادغام با APIهای شکننده بانکیِ شخص ثالث، اعتبارسنجی کنید.
از نمونه اولیه تا تولید
یک نمونه اولیه (prototype) کارآمد، زیرساخت بانکیِ محیط تولید نیست، اما مسیر رسیدن از یکی به دیگری روشن است.
دادههای ساختگی را با APIهای واقعی هسته بانکی (core banking) جایگزین کنید. ابزار get_balance خود را از طریق REST یا gRPC به سیستم دفتر کل (ledger system) متصل کنید. ابزار pay_bill را به سوئیچ پرداخت واقعی خود متصل کنید. وقتی این کار را انجام میدهید، نیازی به تغییر مدل یا منطق گفتگو ندارید؛ شما فقط پیادهسازی مدیریتکنندههای ابزار (tool handlers) را عوض میکنید.
برای مدیریت نشست (session management)، Redis را اضافه کنید. وضعیت گفتگو در حوزه بانکی حساس و تحت قوانین است. شما باید تاریخچه پیامها را به صورت امن ذخیره کنید، آنها را پس از یک زمان مشخص منقضی کنید و اطمینان حاصل کنید که نشست کاربر در درخواستهای مختلف نشت نمیکند. Redis این کار را با سیاستهای TTL و جستجوی سریع کلیدها انجام میدهد.
وقتی ترافیک افزایش یافت، استنتاج (Inference) را به vLLM منتقل کنید. AI Studio برای نمونهسازی عالی است، اما استنتاجِ میزبانیشده (self-hosted) با vLLM روی خوشههای GPU، به شما کنترل بر تأخیر (latency)، دستهبندی (batching) و هزینه در مقیاس بالا میدهد. Gemma 4 در زیر ساختار vLLM به شکلی کارآمد اجرا میشود و رفتار فراخوانی ابزار نیز بدون تغییر باقی میماند.
نکته اصلی
ساخت یک عامل (agent) فینتک قابل اعتماد، کمتر به اندازه مدل و بیشتر به محدودیتهای معماری بستگی دارد. Gemma 4 قدرت استدلال کافی برای تجزیه Pidgin نیجریهای (که دارای تغییر کد یا code-switching است) و مسیریابی مقاصد (intents) پیچیده را فراهم میکند، اما امنیت از حلقه ابزار حاصل میشود. هر موجودی به صورت زنده دریافت میشود. هر پرداخت صورتحساب توسط یک سیستم خارجی تأیید میشود. هیچ چیزی از خود ساخته نمیشود.
کار را در مرورگر با AI Studio شروع کنید، منطق را در یک حلقه Express مستحکم کنید و زمانی که جریانهای گفتگو کاملاً مطمئن شدند، زیرساخت بانکی واقعی را جایگزین کنید. اینگونه است که رباتی را عرضه میکنید که مردم واقعاً میتوانند پول خود را به آن بسپارند.
منبع: Building a Full Gemma 4 Google AI Studio Project: A Fintech Support Agent
انجمن یادگیری اختیاری: GyaanSetu AI on Telegram