MongoDB & Bosch: Discussion on AIoT

MongoDB
August 11, 2021

For more than a decade, the digital transformation of industry has been focused on the technologies that make up the Internet of Things (IoT). As AI and machine learning tech mature, a new field has appeared that combines these trends: AIoT, the Artificial Intelligence of Things, which applies AI to the data collected by IoT devices. Among the firms pioneering this space is the engineering and industrial giant Bosch, which has long been a leader in IoT.

The move to AIoT has allowed for Bosch to create smart products that either have intelligence built in, or have “swarm intelligence” in their back end that allows for the collection of data that is used to improve the products.

In April 2021, Mark Porter, CTO at MongoDB, and Dirk Slama, VP of Co-innovation and IT/IoT Alliances at Bosch, sat down to discuss AIoT. Their conversation saw them touch on what MongoDB and Bosch are working on around AIoT, and where they see the future of AIoT heading.

Bosch’s new focus on AIoT has enhanced their need for a flexible, modern data platform such as MongoDB. IoT devices collect enormous amounts of data; as Bosch adds sensors and new types of data to their products, MongoDB has allowed it to adapt quickly without having to go through a schema redesign whenever they need to implement a change to their products.

As part of their efforts to progress AIoT technology, Bosch and other companies recently created the AIoT User Group, an initiative open to anyone. The group’s goal is to bring end users working on AIoT business and use cases together with technology experts to share best practices around AIoT solutions. This co-creation approach allows for the rapid utilization of best practices to try out and develop new ideas and technologies.

Porter and Slama’s conversation covered many AIoT topics — and a glimpse at the technology’s next steps. For instance, Slama wants to see agility added to AIoT without losing control. In AIoT, there are many features that must be perfect on day one; but there are also a lot of features where you want to continuously improve system performance, which requires an agile approach.

For Mark Porter and Dirk Slama's full conversation, check out the video below!

← Previous

Intern Series: Finding Community While Owning Production - Meet Carolina Obregon

Carolina Obregon is a rising senior at Tecnológico de Monterrey in Mexico who is interning in our New York City office. She’s spent the summer with the DevRel Platform/Education team building a quiz widget for the guides found on docs.MongoDB.com. Carolina has been excited to gain exposure to start-to-finish software development cycles, and in this interview, you’ll get to hear how she has found meaningful support both in her professional circle and from her membership in MongoDB’s Underrepresented Genders in Tech (UGT) Affinity Group. Alex Wilson: Hey Caro, it’s so good to see you! Can you tell me more about how you found out about MongoDB’s internship program? Carolina Obregon: I first applied to MongoDB's Women in Computer Science Summit all the way back in 2019 and while I wasn't accepted to attend that year, I kept receiving emails from MongoDB about blogs and future openings! When the next recruiting season came, I remembered MongoDB's openings and decided to take the chance and apply to the internship program! I was really happy to even get the first interview and even happier when I received the offer. AW: Why did you choose MongoDB for your internship? CO: As a software engineer, it's very important to me to be in a company that has an engineering centric culture so that I'm working with exciting technological challenges, a modern stack, and teammates that I can learn a lot from. Additionally, I really wanted to be part of a company that really cares about their employees, diversity, and company culture, and throughout the recruiting process and talking with past interns and current employees, I found that MongoDB really checked all the boxes I was looking for. AW: That’s great! What has your day-to-day looked like since you’ve been here? CO: The team I work on is part of the greater Developer Relation Platform/Education organization, which is key for all our developers to learn MongoDB from basics to advanced topics required to run MongoDB in production systems. My team specifically is responsible for developing the systems which run MongoDB documentation's website (docs.mongodb.com). Documentation is crucial for MongoDB since the core of the product is essentially targeted at developers. My intern project is creating a quiz widget that is going to be displayed throughout the docs.mongodb.com guides and will ask our users key multiple choice questions about the content that they’re currently reading on. It's exciting that I've gotten to work on this project from start to finish and really experience how the software development cycle works in the industry, from working with the product manager to the product designer and receiving support from the other engineers on my team to make this all happen. AW: Awesome! Anything particularly interesting that you’ve learned? CO: I've gotten to work on a lot with Javascript's React. I had done previous personal projects using this framework, but it has been very interesting getting to work on it in a real life production environment and receiving guidance and feedback from my teammates on how to keep improving my skills. AW: It must be so gratifying to do work with such tangible results and have clear growth opportunities—and that sounds fascinating. Has your team given you much support in this work? CO: They were really good at ramping me up and making me feel comfortable with the work and tech stack from the beginning. Giving me small tasks to start off and after I was comfortable enough, assigning me my own project to develop on my own. The whole team has been super attentive and helpful throughout the whole summer, and making sure that I'm constantly challenged, learning, and getting help in my work! AW: Fantastic! Is there anywhere else you’ve been finding support? CO: Getting the chance to be part of UGT (Underrepresented Genders in Tech) was a very fulfilling and meaningful experience. The Campus Team assigned a UGT mentor for each of us and prepared many events throughout the summer that ranged from talking about our personal experiences to fun game nights. I really enjoyed getting to know other interns and full timers who are also part of the affinity group. In the short time that I spent here, I’ve found MongoDB to be very supportive of underrepresented genders. Taking in the fact that women make up 46% of the intern class, I always felt that I was in a very comfortable and open work environment everytime I came to the office. AW: It’s been so nice to hear that you’ve had such a meaningful summer. There’s one last thing I’d love to hear: you talked about the company culture as part of the reason why you came to MongoDB—what have you found out about the culture since you’ve been here? CO: One of MongoDB's core values is Build Together, and I think that the company culture really stems from that. It is a very collaborative, friendly work environment where your teammates and co-workers legitimately care about your wellbeing both personally and professionally. Interested in interning at MongoDB? Our 2021/2022 Software Engineering Summer Internship for the US is now live and accepting applications for students

August 6, 2021
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