AskPorto: Building Intelligent Data Analytics with Databricks Genie

Summary

The Central Provident Fund Board of Singapore built AskPorto, a conversational AI solution powered by Databricks Genie spaces and multi-agent orchestration, enabling employees to query complex data without requiring coding skills or domain expertise.
AskPorto combines Retrieval-Augmented Generation with Databricks' native governance through Unity Catalog, and implements production-grade security using token-swap with on-behalf-of authentication across a multi-VNet isolation architecture.
The video covers practical lessons on metadata refinement, business language mapping, and the development strategies that scaled Genie from proof-of-concept to enterprise impact across CPFB's organization.

AskPorto: Building Intelligent Data Analytics with Databricks Genie

Data access alone doesn't empower decision-making. The Central Provident Fund Board of Singapore faced a critical challenge: employees and business users needed insights from complex data without requiring advanced coding or domain expertise. Traditional querying methods created bottlenecks, fragmenting analytical capabilities across the organization.
Learn how CPFB built AskPorto, a unified conversational AI solution powered by Databricks Genie spaces with multi-agent orchestration. Discover how they combined Retrieval-Augmented Generation with Databricks' native governance through Unity Catalog, implemented production-grade security with token-swap authentication, and scaled Genie from proof-of-concept to enterprise impact. The presentation covers practical lessons on metadata refinement, business language mapping, and the development strategies that transformed natural language queries into reliable data insights across the organization.
🤝

Chapters

FAQs

What is AskPorto and what problem does it solve for CPFB?

AskPorto is a conversational AI solution built by the Central Provident Fund Board of Singapore that enables any employee to query organizational data using natural language, without requiring coding skills or data domain expertise. It was built on Databricks Genie spaces to eliminate the bottleneck created when data insights were accessible only to technical users.

How does AskPorto handle security and data governance?

AskPorto uses multi-VNet isolation for network-level security and implements token-swap with on-behalf-of authentication so that queries execute with the permissions of the requesting user rather than a shared service account. Unity Catalog on the Databricks Data and AI platform enforces all data governance boundaries throughout the system.

How does CPFB's multi-agent architecture route queries in AskPorto?

AskPorto uses multi-agent orchestration to route incoming natural language queries to the appropriate Genie space based on the data domain being queried. This allows the system to answer questions across multiple subject areas while ensuring each query is handled by an agent specialized in the relevant data context.

What lessons did CPFB learn when scaling Databricks Genie to production?

CPFB found that metadata quality and business language mapping were critical — Genie's ability to interpret queries accurately depends heavily on table and column descriptions being written in the language that business users actually use rather than technical naming conventions. They also developed a structured testing strategy to validate Genie responses before broader rollout.

Full transcript

[00:09] Hi, good afternoon. I'm Benedict. Together with me is Alex and Jinning. We're from the Central Provident Fund of Singapore. Right, here we're here today to share with you about our project Ask Portal. Right, in this presentation there's some forward-looking statements.
[00:25] Um remember to take your do the survey at the end of it. Right. Ask Portal is our agenda AI solution powered by Genie and NLLM. And it's called Ask Portal as something
[00:40] transformative. It puts the power of data into the hands of every user. No technical expertise is required. We did not arrive here by accident. It is a result of intentional forward-thinking investment in our data
[00:55] capabilities. Step by step. We moved from silo reporting to integrated analytics. And now we are pushing the realm of predictive AI-driven insights. In other words, we've gone through from looking at the
[01:11] rearview mirror into charting the road ahead. We'll start with a video of our journey over the last decade or so.
[01:28] Data has been a key part of our work at CPF Board. As we launch the Unified Data Platform or UDP Phase 2, let's travel back in time to see how far we have come. The first mainframe computer was installed in CPF Board in 1963 to automate the manual ledger accounting
[01:44] system. We used punch cards to update the mainframe computer and keep track of CPF members' latest contributions. We introduced the Statistical Information Database or SIB, in 1995 to help us generate important statistics.
[02:02] SIB helped us standardize statistical definitions and derivation of statistical figures. It gave us a consolidated view of data in nine subject areas and access to some key business data. SIB was a foundational building block of our data journey, but to support more
[02:18] complex statistical analysis for policy reviews and operations, we launched the Data Analytics and Information Enterprise Laboratory, or Daniel, in 2014. Daniel served as a data repository for most of our key business data and
[02:34] allowed us to leverage tools like Excel, Tableau, SAS, Python, and R for more sophisticated data analysis. Since it was launched in 2014, Daniel has been used by 35 departments and had 10 times more users than SIB.
[02:51] With advancements in cloud computing, big data processing, and data science, we embarked on the Unified Data Platform to grow CPF Board's capabilities in extracting insights from data. UDP seeks to empower CPF Board users by
[03:06] democratizing data and tools. Users can search for data easily, exploit data to generate insights, and deploy machine learning models for operations. Right. So, over a decade ago, we made a big bold
[03:23] step. We would when we were talking about digital transformation, we placed data exploration at the heart of our transformation roadmap. It wasn't a side initiative. It was a strategic commitment. From the foundation, we set ourselves an
[03:40] ambitious goal to become a truly data-smart organization. It was about collecting more data, building its purpose, and making data accessible yet secure, building comprehensive and high-quality data
[03:56] sets, developing world-class data scientist capability. Data is now woven into every decision that we make at the organization level.
[04:12] To be honest, there were a lot of roadblocks when we started this journey. Our data lived in silos, scattered around multiple systems. Pulling together a single coherent view was painful and slow.
[04:28] On top of that, we had no single unified platform. Everyone was working on different tools, duplicating efforts and reinventing the wheels. And when we wanted to push into advanced territory, machine learning, predictive modeling,
[04:46] we hit a wall. The The individual laptops just couldn't handle it. It kept crashing. We wanted our people to use data, but the infrastructure was standing in their way. Something had to change.
[05:01] And Alex will cover what we did and how we did it.
[05:23] Thank you, Ben. Yeah. If you ever felt the pain of fragmented data coupled with silo systems, you know exactly what we were actually facing with. We were actually not looking for a quick patch. We wanted a paradigm shift. Moving away from localized, restricted
[05:39] hardware was the only way to overcome our historical challenges. And that's why we chose to build on the cloud. First, we wanted a one-stop platform. We created a central space where users can easily access, visualize, and
[05:56] understand our core business data without jumping through tools and data sources. Second, the ability to scale. Our platform adopts adapts to diverse requirements, scaling both vertically as well as horizontally
[06:14] to cater for everything as simple as just reading a simple data to generative AI workloads. Thirdly, a robust ML framework. We enforce proper governance across an automated machine learning life cycle,
[06:30] completely completely eliminating the nightmare of bespoke model hosting as well as environment setup. Finally, in terms of our platform roadmap, future proving is crucial. We do not want to be locked into a rigid
[06:46] specifications, versions, or standards. Instead, we wanted our platform to main remain at the forefront of technology. The product team focuses on the technology, and we focus on solving our internal use
[07:02] cases problems. Next, I'll be sharing on the system architecture of how we actually set it up. Our UDP platform, Unified Data Platform, is built on entirely on the Microsoft Azure tech stack,
[07:18] aligned closely with our government roadmaps. It handles incredibly diverse data, whether it's actually legacy mainframe files, flat files, or modern JSON files via SFTP, as well as API.
[07:36] All secured with both encryption and decryption. Looking at our key components, Azure Data Factory serves as our core orchestration engine, triggering Databricks notebook using our own in-house built ingestion framework.
[07:52] We couple Logic Apps along with Azure Sentinel to run continuous monitoring and alert notification. While pushing our core While pushing our core analytics to Power BI for dashboarding as well as
[08:09] Neo4j for graph relational use cases. To keep To keep this massive operation safe, we integrate a custom tokenization service right into the ingestion pipeline to automatically safeguard
[08:24] sensitive data. And to wrap it all together, we host our machine learning models on the Azure Kubernetes service following the ML MLOps ingestion standards.
[08:39] Using Azure API Management service to let Databricks talk seamlessly with our on-prem as well as other open systems. Now that you have seen the general landscape of our platform components, let's take a
[08:55] layer deeper, right, to see how the data actually lives, breathes, and transforms across the environment. Okay, this is going to be quite heavy. Let me walk you through how the data
[09:11] actually moves. Most of it originates from our non- our on-prem systems. The moment actually it arrives, we handle any necessary decryption and tokenization automatically. The data then flows through our modern architecture,
[09:27] landing first before passing through the bronze, silver, and gold layers. Because security and authorization are our top priorities. Sensitive data is enc- re-encrypted before even it hits the bronze layer.
[09:48] When authorized users need to explore this data in Databricks, we provide secure views that dynamic- dynamically decrypt on the fly when they query for it. To help our users navigate the environment, all our data dictionaries reside in
[10:04] Azure Purview for easy exploration. Meanwhile, the actual access is strictly managed through the Azure AD Entra ID groups, which are synced directly into Databricks. I know these last three slides were quite technical,
[10:20] but the but the architecture is the essential foundation. Ben will be sharing on the tangible, real-life problems that our platform actually managed to solve. Over to you, Ben. Thank you, Alex. So,
[10:36] what happened when we when we had Azure Databricks in place? The impact was immediate, and it was real. Right? I'm going to talk you through three examples of what did it mean to us, creating tangible value for our citizens, empowering our staff
[10:52] capability that they never had before. First, our contact centers. I think everyone's very familiar with contact centers, right? We receive more than half a million calls a year in multiple languages, serving an incredible diverse citizen base and multiple schemes.
[11:09] The scale alone is staggering to us. The question was, how do we put the right people in the right seats at the right time, when demand swings wildly and unpredictably? So, we built a forecasting model.
[11:24] It does not just predict call volume. It simulates questions across the different scenarios. Think of it as a crystal ball for our predict uh for our operations. Instead of reacting to surges when it happens, we now anticipate and deploy
[11:40] resources before the phone starts ringing. As a result of this, optimized staffing, shorter wait times, and fundamentally better experience for every member who picks up the phone.
[11:59] The other way that our citizens reach out to us is through our digital platforms. We serve We receive more than million right ins a year through our different channels. It's a massive volume of citizens inquiries that flow in. The challenge was we have a lot of
[12:15] schemes. Members often select the wrong category when writing in to us or filling up the forms. What this means to us is that a lot of the inquiries get routed wrongly. And our staff spend a lot of time
[12:33] manually redirecting them, and the questions take a longer time to be responded to. As a result of this, we built a machine learning model with ML Ops, training on the Databricks, deployed on AKS, and now
[12:50] the moment an inquiry comes in, a real-time API calls and routes it to the correct department. And this has cut wrongly routed cases by a third, meaning that responses and smoother experience for the people we serve.
[13:07] The third example is closer to me because we built us recommenders for our staff. We have a wealth of learning resources that our staff have gone through based on the different criteria like your
[13:24] different um job scope, your seniority, and your progression pathway. Previously, staff have to go into this wealth and search manually. What we did was we built a personalized
[13:39] learning solution combining UDP with Neo4j's knowledge graph. We pulled data from multiple sources like SAP and the offline training programs that we run, apply machine learning to the map to map the relationships between the
[13:56] skills, roles, and courses. We then layer an LM-powered chatbot on top of that. So, now staff will just have to type in "What's next for me?" They get a tailored recommendation based
[14:12] on their role, skills, and growth trajectory. It bec- It is a personalized learning at scale. Now, we make sure that every person in our organization stays sharp and future-ready.
[14:27] Right. So, what we have done today is this first uh we have moved from a fragmented siloed data to a unified data platform. It has answered the questions that we raised earlier. Now,
[14:44] what This is a transformation we are proud of. We are not done yet. We are just getting started because of how technology has evolved and what is available to us. Jenny will bring us through what's our
[14:59] next step. Yeah. So, we have come a long way, but we realize a simple truth. Giving people access to data doesn't mean they can use
[15:15] it. We found two barriers. First is data context. We can give someone access to a table, but strange column names means nothing if there is no domain knowledge. Without that knowledge, people spend too much time feeling figuring out what
[15:31] questions they can ask. The second barrier is coding skills. Even with a great platform, if someone still needs to write complex SQL or Python to get a simple answer, it isn't true self-service. It creates a dependency where business users wait on
[15:49] their more technical colleagues for daily insights, which slows down decision-making. Ultimately, our employees had to be either coding expert or schema expert to get a daily answer. To remove this friction, we decided to
[16:04] explore a generative AI. This drove us to build Ask Portal. Our goal is to give our users insight on demand, not just raw tables. To bridge the data context gap, we use RAG to retrieve the relevant business
[16:21] terms and domain knowledge behind the scenes. The tool interprets the user's intent and fetches the required domain knowledge, so anyone can start asking questions without feeling lost. And to bridge the coding skills gap, users simply ask questions in natural
[16:38] language, and Ask Portal translate them into data queries. Users do not need coding language for daily discovery. Our ultimate vision is to allow users to get insights across different business areas using just natural language.
[17:01] To show you how this looks, here is a quick video demo. Ask Portal is a unified generative AI solution that lets our users converse with policies, discover data, and generate stats, all from a single chatbot, without coding. First, let's
[17:16] see how someone can ask about our UDP policies and processes. For example, if a user doesn't have access to UDP, we can just type, "How do I onboard to UDP?" While the agent is thinking, what is
[17:32] actually doing behind the scenes? It's searching through our process documents. It finds the right document and section of the document, extracts that information, and outlines the exact steps clearly for the user. Next, what if a user already has access
[17:49] and wants basic stats? We can use the same chat box. In this second example, the question is, "How many CPF members are there as at December 2025?" Ask portal now acts like a data assistant. It reasons about the query,
[18:06] looks into our data catalog to fetch the relevant tables and columns, and generates the statistics. Finally, we can easily follow up with a conversational question, like, "What is their total net balance?" The agent remembers the context of our
[18:22] conversation. Without retyping all the filters just now, it realizes that they are refers back to the exact same group of members that we found out just now. So, it simply looks for the net balance data column and generates the final
[18:38] number for our users. This means they can just chat naturally to slice and dice the data. As we can see from the video, all three of these different queries, from answering process questions to executing data calculations, are handled
[18:53] seamlessly inside this same chat. While the user experience is a simple conversation, here is how the workflow behaves behind the scenes.
[19:09] When a user enters a query, Ask portal interprets and routes it to one of the two specialized agents. For UDP policy or process questions, the query goes to the wiki agent. This agent is connected to our vector store that contains our wiki documents on policies
[19:25] and processes. And if we are querying on numbers and statistics, the query will go to the data agent. This agent is connected to our data catalog vector store and it also uses Databricks Genie tool to execute the data query. Once the chosen
[19:42] agent retrieves the information, the system generates a clear response in plain English back to the user. To handle database queries smoothly, our data agent uses Databricks Genie spaces.
[19:58] It gave us two major benefits out of the box. The The first benefit is AI/BI intelligence. Genie comes with a built-in knowledge store where we can store our synonyms, column descriptions, and example SQL queries. It uses this documentation to
[20:15] translate plain English into accurate data answers, saving us from having to build this translation layer ourselves. The second benefit is governance. Genie integrates natively with Unity Catalog, UC, which means all our
[20:31] existing data access rights and security rules are automatically inherited and respected by the AI agent. This is important for us because we handle data with varying levels of sensitivity and ensuring that restricted
[20:47] information stays secure is a core requirement. To see this in action, let's use this example query. What was the total number of active employment CPF members as at December 2025?
[21:03] First, the main agent reads the question and realizes the user wants numbers and statistics. So, it routes the request to the data agent. Next, the data agent maps the query to targeted genie spaces built for specific
[21:19] topics. In this case, member demographics. By routing the request this way, the system doesn't try to query our entire database at once. It finds the right genie space and focuses its execution within those specific tables. This makes
[21:36] the final answer more accurate for users. Next, Alex will bring us through the technical aspects. Thank you, Jaylin. Okay, so when we decided to integrate
[21:51] agentic AI into our unified data platform, we knew we couldn't just slap a large language model into our existing database or platform. In a strict government environment, security and governance are non-negotiable. To empower our platform with AI safely,
[22:09] we built our solution as portal, as shared earlier, upon these three foundational pillars: interface, orchestration, and compliance. We designed the three entirely isolated, independently managed layers. The chat interface, the orchestration
[22:25] engine, and the data context are separate are completely separated. This isn't just a performance, it's a deliberate architectural choice to ensure strict compliance, where every prompt and data retrieval action is
[22:41] governed by absolute access control. Okay, I'll be covering on the dry stuff. Just bear with me for a while. Let's look at how this actually maps out to our existing Azure infrastructure. We have evolved our existing data bricks
[22:56] foundation into a highly secure multi-VNet environment. VNet stands for virtual environment. In the top left-hand corner, VNet A, we have our front-end subnets hosted hosting the RSU DP web.
[23:14] RSU DP web front-end within a secure app service environment ASE. This is the isolated entry point for all our users. In VNet B, our back-end subnet, the heavy lifting happens here.
[23:30] We use Azure Kubernetes service to host our ask portal pod containers and Azure Key Vault for securing secrets. In VNet C, the request crosses into the Databricks host and container subnets.
[23:45] This is where the Databricks Genie workspace lives, interfacing natively with our Unity Catalog UC, and SQL warehouses to safely query the data and metadata. Finally, we maintain a
[24:01] separate VNet D specifically for PostgreSQL SQL for state management as well as contextual database management. By compartmentalizing these tiers, the application tier from the database and Genie tier,
[24:17] we ensure that a compromise in any of these layers do not breach into our core system data assets. Now, isolating that what is great, but there's not a lot of it but who's looking at but how do we actually manage
[24:32] our core or how do we manage the user identity when our agent is making the query on the user's behalf? How do we prevent privilege escalation? Privilege spillover. And the answer for it is actually using
[24:49] the on behalf of or OBO, which involves token swap mechanism. Here is the flow. For phase one and phase two, the user logs in via the single sign-on page. Microsoft Entra ID authenticates them
[25:07] and issues token A. This token is strictly scoped only for the Ask UDP front-end application. When phase three, when the user asks the AI for a question that requires that request moves into our internal
[25:22] application layer, our orchestrator takes token A, reaches back to Entra ID, and executes a secure system context token swap to get token B, the token specifically scoped for
[25:38] Databricks. Phase four, which is the final phase, the Ask portal process takes this Databricks-scoped token B and forwards it as a bearer token to the Databricks Genie API. Because Databricks validates this
[25:54] specific token B natively against the Unity Catalog, the AI is constrained entirely by the user's actual true identity and permissions. The AI can only see and query what the specific user is authorized to see.
[26:11] As such, we achieved natural language querying without compromising a single aspect of our existing role-based access control design. Next, Genie will be sharing on the lessons and the learning experiences that we have gone along the way.
[26:30] Thank you, Alex. Next, we want to share a few lessons we learned while building Ask portal with Databricks Genie spaces. Our first takeaway is that metadata is everything. While we already had a data lake catalog in place, we found many of
[26:47] our existing definitions too vague for an AI. Human analysts have an advantage. They use their intuition and prior business knowledge to fill in the blanks. And AI doesn't have that implicit context. When
[27:02] we spin up a Genie space, we are essentially onboarding a new automated team member that needs everything spelled out clearly. So, we went back to refine our definitions inside UC. First, we focused on writing descriptive, clear comments
[27:18] for tables and columns. Second, we translated cryptic database abbreviations into plain business language. This reduces hallucinations and ensures Genie pulls the relevant data our users are looking for.
[27:37] Our second lesson is to actively teach Genie our business language. Out of the box, LLM doesn't know our internal acronyms, unique rules, or how our tables link together. To bridge this, we explicitly map our tables' relationships and join paths
[27:53] ahead of time. This lets Genie safely navigate across tables without having to guess. We also predefine our filters and calculations as reusable SQL core expressions. By mapping everyday business terms like
[28:09] active members directly to these code snippets, we created a reliable bridge. We also provided a library of example SQL queries for common questions. While the expressions we just looked at
[28:25] at the previous slide they handle individual filters and calculations, these example queries show Genie the entire end-to-end query structure. They show Genie the exact logics, join patterns, and parameter structures to
[28:40] replicate. When we first started, we wrote long paragraphs of text instructions to explain how our schemas work. But we found that extract text prompts, they are easily misinterpreted. We now keep text instructions like
[28:55] reserving them for general behavioral rules. For data logic, giving Genie concrete SQL examples to follow is more reliable. Our final lesson is about development strategy. Build, measure, optimize, and
[29:13] repeat. When we first saw Genie AI in action, we were tempted to connect all of the tables in our data warehouse at once. We learned that handling everything at once makes debugging overwhelming. We adopted a step approach. We started
[29:29] small by focusing only on our most requested metrics from single tables. This gave us a stable, reliable foundation. Only after we were confident in single table accuracy, did we start introducing multi-table joints. Taking
[29:45] it one step at a time kept our errors manageable and stopped our mistakes from compounding. The second part of this loop is continuous benchmarking. We moved away from by checking a few queries here and there to a more rigorous benchmarking
[30:01] process. We put together a static test suite of golden questions paired with pre-verified SQL answers. When a test run drops in accuracy, we isolate and fix one variable at a time, either changing a single description or prompt
[30:17] before we retest, ensuring we know exactly what moved the needle. Treating our Genie spaces as living, continuously reviewed environments took some patience, but it's what helped us transform our Genie spaces into a dependent tool for our users.
[30:37] This brings us to the end of our presentation and to the core mission behind Ask Portal. Our goal wasn't just to deploy a new AI tool. It was to fundamentally change how we work, transforming data from a technical asset into an everyday capability for everyone. Thank you for your time and we
[30:55] are happy to take any questions at a site.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.