Democratizing Data Access With Plain English, Cogram, and MongoDB

Marcus Eagan and Ricardo Wölker
April 22, 2022 | Updated: April 25, 2022
#Startups

Access to information is important for our world and the applications that power it. Today, the disparity in access has narrowed, but not enough. The proliferation of the document database and its flexible data model has unlocked a velocity and freedom that SQL systems will never unlock. It’s time to remove the burden of query languages for users early in their journey.

That’s why we are launching an early pilot with Cogram, the startup building the world’s first Mongo Query Language (MQL) generation platform for natural language. The early-stage company is on a mission to democratize data access by allowing users to query data irrespective of their technical background. Cogram is working toward a future in which humans can access and manipulate any data through natural language.

Cogram is partnering with MongoDB to enable language-driven data exploration. While it is still early days, users can log in to the tool, enter an English-language question for five collections from our sample dataset, and execute the generated MQL to see the results.

Here are some questions to get you started on the Sample Supply Store dataset:

  • Find one sale.

  • What's the average customer satisfaction in Denver?

  • What's the percentage of customers in Denver who used a coupon?

  • How many users have an email address that contains ‘em.uy’?

  • Find two sales.

  • Get the last inserted sale.

  • Show all store locations.

  • Show all unique tags.

  • What are the top five tags?

  • Find all customers who use gmail.

  • Show me all customer email addresses that end on ‘.sh’

  • What are the three most common store locations?

  • What's the average price of all items?

  • How many customers used a coupon?

  • How many times was each item sold?

Additionally, we’re excited to have Cogram included in MongoDB for Startups, our program for early-stage, high-growth startups. Designed to help founders and CTOs build and grow data-driven organizations with MongoDB, the program provides a wide range of resources, including MongoDB’s best-in-class data platform, personalized technical advice, and access to our robust developer community.

Get a first look by signing up for a Cogram account and testing it out.

← Previous

Celebrating Earth Day With Three MongoDB Customers

Every April 22nd, citizens across the globe come together to celebrate the environmental movement on Earth Day. This year’s official theme is " Invest in our Planet ." According to the Earth Day organization, “for Earth Day 2022, we need to act (boldly), innovate (broadly), and implement (equitably). It’s going to take all of us. All in. Businesses, governments, and citizens — everyone accounted for, and everyone accountable. A partnership for the planet.” On this important day, we’re highlighting three MongoDB customers that have taken great strides to make a positive impact on our environment. They are shining examples of the power of MongoDB and what it means to be eco-friendly. University of Bremen At Germany’s University of Bremen , the Collaborative Research Center (CRC) initiative Farbige Zustände is a cross-disciplinary effort to reinvent an entire field of research: the discovery of new materials. “It’s not just harder, lighter, strong materials,” Dr. Nils Ellendt, CEO of the CRC, says. “It’s finding materials that need less refining, that are more compatible with a sustainable environment. How few elements can we use, not how many.” When the CRC first planned its data infrastructure, the company looked at standard structured databases, but it quickly realized that the datasets researchers would be using were quite heterogeneous and better suited to unstructured database techniques. That’s where MongoDB came in. MongoDB proved it could handle unstructured data at scale, so the CRC built its entire testing process around it. Soon after, the company determined that MongoDB was well suited for its unique approach. The Centre has its sights on pioneering a complete revolution in materials science, not simply in the creation of a massive new catalog of potential engineering materials, but also in pioneering data and automation in creative engineering. Read our full profile of the CRC “Farbige Zustände.” Journey Foods Journey Foods is a machine learning–powered software platform for food companies, designed to revolutionize the future of food. Just a few years after its launch, Journey Foods has raised more than $2.5 million from investors and partnered with global consortiums such as Future Food Network, FoodTank, and the University of Chicago on sustainability and data. “We are trying to focus on developing our service to accurately provide nutrition insights, sustainability insights, and help save our customers money,” said Riana Lynn, CEO. “We are prioritizing partnerships that will help us build out a big and dynamic ecosystem.” Lynn said the company chose MongoDB because of its seamless user experience, ease of scalability, and recommendations from other companies. She cited the consistent and always available support and follow-up from MongoDB; because of that, her developers appreciate how easy it is to use the platform, and to share and collaborate on different projects. Read our full interview with Journey Foods’ CEO. Kode Labs The commercial and real estate markets are being transformed by new technologies that reduce the carbon footprint of these energy-intensive businesses. Kode Labs was born because its founders recognized the importance of sustainable buildings, and how they rely on advanced software to achieve LEED and other sustainability certifications. Kode Labs launched in 2017 to provide intuitive, easy-to-use software for building management that enables sustainability, operations efficiency, and comfort. The company uses MongoDB Atlas for a fully managed database that allows it to effortlessly deploy new projects, infrastructure components, and more when starting to work with a new client or building out further projects with an existing one. “Everyone wants to be more energy efficient, healthier, and have modern places to live and work,” says Etrit Demaj, co-founder of Kode Labs. With MongoDB Atlas, "we help building managers and construction firms deliver on these growing expectations.” Read more about Kode Labs’ mission to support sustainable buildings.

April 21, 2022
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024