What We're Reading

MongoDB
November 27, 2013 | Updated: May 22, 2015
#Company

We're gathering up this week's MongoDB News a bit early for the holiday. Have a happy Thanksgiving!

MongoDB News: Topps Modernizes Trading Cards With Apps Built on MongoDB

Information Week: Big Data Profile-Eliot Horowitz of MongoDB

Inc.: The Hottest Startup You’ve Never Heard Of.

OpenLife: Translating Reliably Between XML and JSON

ObjectRocket Blog: Tapping Scalability (And Good Beer) With ObjectRocket and MongoDB

Laura Czajkowski: MongoDB MUG March Madness

MongoDB Blog: Why iBE.net Chose MongoDB

Antoine Dollmaier: Storing Syslogs with MongoDB and Syslog-NG

LeanStack: How Authy Built A Fault-Tolerant Two-Factor Authentication Service

← Previous

Employee Profile: Will LaForest

As part of a series showcasing our wonderful employees, we're featuring interviews each week. You've already met Brendan Coleman , our director of Business Development, and Barrie Segal , the the Project Manager for the Development Experience team. We're excited to introduce you to Will LaForest, the Senior Director of US Federal Sales. What is your role at MongoDB? What department do you work in? I head up the Department of Tax Reclamation, based in Washington, D.C. When I started, I told Dwight I would sell the government enough software to get his tax money back. I think I have a lot of work left to do. Officially my title is the Senior Director of US Federal Sales, but that doesn’t sound nearly as cool. Where were you before MongoDB? Why did you choose to come to MongoDB? Previous to my stint at McDonald’s as head fry chef, I worked at MarkLogic as a Principal Technologist. When Max (Schireson, the former COO of MarkLogic) joined MongoDB, I decided to re-evaluate the NoSQL space. I felt Dwight and Eliot made three really smart bets and I could easily see MongoDB dominating the space in the tech community. Using a document-based model and JSON specifically, native language drivers, and an open source business model (a no brainer in my opinion) all led me to talk to MongoDB about a position. But ultimately it was the people here the made the choice easy. After spending an hour interviewing with Dwight, who was the CEO at the time, I knew I had found a new home. He totally called me out on my weak Lisp skills and we spent 20 minutes talking about inverted indexes. What’s your hometown? I grew up in Queeche, Vermont until I was five. Then my family moved to D.C., but no self-respecting Washingtonian actually admits they’re a Washingtonian Did you have previous experience using MongoDB before you arrived? If so, how are things different now that you work at MongoDB? If not, how did you learn MongoDB and how was the education process? I downloaded MongoDB and played around with it for a few hours, but didn’t have any substantial technical experience with it. The domain and the principles of MongoDB were very similar to MarkLogic, so absorbing the concept of MongoDB took little time. It was harder to adapt to the open source business model. It’s a dramatically different approach than if you’re selling commercial software, where you spend massive amounts of resources on a relatively small number of deals. With the government in particular, there are many more hoops to jump through. Convincing people to use new open source software in production is challenging. There are mountains of certification and accreditation requirements, approvals, etc. The model of engagement was very different than what I was used to, and resources were much more limited. But it’s worth it. Have you had any personal projects where you’ve used MongoDB? My only personal project with MongoDB is trying to use it to finance my private island. I have been working on some Minecraft mods with my son but haven’t found a plausible excuse to make him use MongoDB. How do you get to work? I usually opt for a rickshaw pulled by a low-paid congressional intern. It’s great for the environment. When that’s not available, I’ll usually drive. There was a time when my family only had one car, so for some of my meetings I would put on my nice clothes, ride my razor scooter to the bus, take the bus to the metro, and then razor scooter through the metro to get to meetings. What’s a typical day (or week) for you? When I have a typical day or week, I’ll take some notes and let you know. It will likely involve a polygraph, congressional lobbying, and a shady business lunch in a subterranean restaurant. What do you love most about MongoDB? Definitely the people. I love everyone I work with, except for Dan Pasette. He’s taller, smarter, and better looking than me, and it’s just not good for my self-esteem. DISCLAIMER: Will and Dan get along great, and Will does not harbor any hard feelings towards Dan based on his appearance or intelligence. What’s the most challenging project here at MongoDB that you’ve worked on, and how did you succeed? I’d say our last deal with a not-for-profit venture capital firm. With most deals you’re only selling to one customer. But we had to convince several secret agencies to buy. Each one had to be sold to individually, and they had to agree how they would cooperate, how the subscriptions would be split, etc. It's especially difficult to get these groups to work together, let alone make a deal. We couldn’t even meet some of our end customers face to face and had to work with them via proxy. Ultimately we closed the deal, but it was definitely a challenge. What’s the most rewarding experience you’ve had working here so far? I don’t know if there’s one experience or one moment, but growing the federal team has been extremely rewarding. Every time we close a deal or deliver something on the technical side, I get an adrenaline rush. Ultimately one of the reasons I joined MongoDB is because there’s a real opportunity to help the government do things that are very difficult to do, while remaining cost effective. What’s your favorite lunch? I love a good Fiber One bar. They’re super quick and portable. My favorite flavor is the one they sell at Costco: chocolate chip, I think. I also drink a lot of milkshakes; chocolate malt is my favorite. Interestingly, I and four other members of the federal team are vegetarians so there is a lot of vegetarian food consumed. I’m a bit of a pizza aficionado; D.C. has terrible pizza, so every time I’m in NYC I try to get even a mediocre slice. Name one secret skill you have, unrelated to work. I’m actually a legendary dungeon master. Sometimes I roll a combination of 20 sided and 12-sided dice. Kindle or book? What’s your favorite book? I read books. My favorites are The Painted Bird by Jerzy Kosinsky and 100 Years of Solitude by Gabriel Garcia Marquez. Describe your perfect weekend. A lot of sleep, some ping-pong and video games What are your plans for Thanksgiving? We are flying up to the Adirondacks to celebrate with the rest of my family. My parents aren’t that bright and they actually retired to upstate New York. I think they must have been holding the map upside down when they made their decision. There’s supposed to be 30 people at dinner; sounds like a nightmare. What is your favorite part of the Thanksgiving meal? Do you cook at all? It’­­­­s not Tofurky. Normally I cook the turkey for my carnivorous family. I layer bacon all over the bloody turkey. Bacon is one of the few things I still crave as a vegetarian so I have to live through others. My favorite part is the pies. If you're interested in joining the MongoDB Team there are a number of open positions available in Engineering, Sales, Marketing, and Business Development. To learn more about open roles at MongoDB, please visit the MongoDB Careers Page.

November 27, 2013
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