Online MongoDB Classes Start Today

MongoDB
October 23, 2012
#Releases

A guest post from Andrew Erlichson, 10gen’s VP of Education

Free, Online MongoDB classes start this week and there is still time to join one of the two courses: MongoDB for Developers and MongoDB for DBAs.

I am teaching the developer course along with Richard Kreuter. Richard is a lead consulting engineer and has significant experience with MongoDB users around the world. Dwight Merriman, founder of 10gen and one of the creators of MongoDB, will be teaching the MongoDB for Administrators course.


Right now we over 20,000 registrations for the classes. Lots of folks have contacted us asking what they should expect from these courses, so we thought we’d share some information on what we’re planning. 

The Basics 

The courses will run seven weeks. Each week we will be providing video lectures, broken up into small bite-sized chunks. Most chunks will include a small quiz to help you make sure you are understanding the material. Quizzes won’t count toward your grade. There will weekly homeworks (with due dates!) and a final exam in each course.

Everyone will be expected to install MongoDB on their own computer to do the weekly homework assignments. We review how to do that in the class.

What does the developer course entail?

For the developer course, the class project will be to build a blog. We will be doing most of the teaching in Python, using Pymongo (the Mongo driver) and bottle, a lightweight web framework. Our example code will be in those technologies. We will be providing material on those technologies if you have never used them before.

Do we need to know a specific programming language to participate in this course?

Students can use any supported language for the homeworks. We will be checking the output of the homework, not the exact way you programmed the solution, so if you prefer another supported language, you can use that instead. But working in another language will require more work since we won’t be providing sample code.

Is there going to be any support for new students?

Given the number of students, we won’t be able to provide one-on-one help but plan to provide several ways to get your questions answered. There will be forums and some weekly office hours to get help. For office hours, only a small percentage of the questions raised will get answered. In addition, several of the MongoDB User Groups will be hosting weekly in-person study groups so you can collaborate with others taking the course. 

Do I need to watch the lectures as soon as they come out to keep up with the course?

You don’t need to watch the lectures at any particular time, but there will be weekly assignments to keep you in sync.
I’m having a hard time deciding which course to take. Any suggestions?
You can take both courses simultaneously. There will certainly be some redundancy. For example, both DBAs and developers need to know how to query the database. Both courses will cover the Mongo shell, but the DBA course will focus on issues of scaling, sharding, and replication to a much greater degree than the developer course.

This time isn’t working for me. Will you be offering the courses again?

We plan to re-run the courses in January so don’t worry if you can’t do it now.

Best of luck in the course. We’ll see you online!

← Previous

This Week in MongoDB: October 22-28

Hello everyone, here’s what’s going on in the MongoDB World Upcoming MongoDB days: MongoDB Boston, October 23 A Morning with MongoDB Milan, October 24 MongoDB Bangalore October 26 A Morning with MongoDB, Paris , November 7 MongoDB Melbourne, November 9 MongDB Sydney, November 12 MongoDB Chicago, November 13 A Morning with MongoDB, Brussels, November 14 MongoSV, December 4 MongoDB Tokyo, December 12 Upcoming Webinars: October 24: How and Why Leading Investment Organizations Are Moving to MongoDB October 25: Ensuring High Availability for Real-Time Analytics October 30: Managing Social Content with MongoDB November 1: Building Web Applications with MongoDB and Spring November 6: Managing Real-time Risk Analytics with MongoDB User Groups and Events this Week October 21-22: Brendan McAdams at PyCon Finland October 23 10gen at Red Hat Government Symposium NYC MongoDB User group at Dataweek October 24 MongoDB Boston NYC MongoDB Study Group at 10gen Inaugural Milwaukee MongoDB User Group October 25 MongoDB Bangalore Workshops Thames Valley MongoDB User group October 26 MongoDB Bangalore Things to read: Congrats to 10gen partner, MongoHQ on their $6 Million round Things I wish I knew about MongoDB a Year Ago Writing Reactive Web Apps with ReactiveMongo and Play! Have something to add for next week? Let us know! Tagged with: mongodb, event, events, community, webinars

October 22, 2012
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