AI-enhanced claim adjustment for auto insurance

Solution overview

The insurance industry has the daunting challenge of processing claims efficiently and accurately. Traditional methods are fraught with inefficiencies, primarily due to:

• Time-intensive manual processes: Adjusters typically spend extensive time manually comparing new accident photos with historical claims, a process that is both slow and error prone. In our example, a car has just crashed into another vehicle. The driver gets out and starts taking pictures of the damage, uploading them to their auto insurance app, making the photos available to a claim adjuster. Typically, the adjuster would painstakingly comb through past claims and parse guidelines to work up an estimate of the damage and process the claim.

• Fragmented data systems: Vital information is often dispersed across multiple, disconnected systems, making data retrieval and analysis a cumbersome and error-prone task.

• Volume of unstructured data: The sheer amount of unstructured data, such as images and documents, poses a significant challenge in terms of storage, retrieval, and analysis, often leading to delays and inaccuracies in claim processing.

• Inconsistency and inaccuracy: The manual nature of traditional claim processing can result in inconsistent assessments and potential inaccuracies in estimating claims, impacting customer satisfaction and financial outcomes.

Our solution addresses these challenges by implementing an AI-driven vector search system within a centralized vector database. This approach offers several benefits:

• Reduces time and effort: Automates the comparison of accident images, significantly cutting down the time required for adjusters to make informed decisions.

• Integrates data seamlessly: By using MongoDB Atlas, our solution unifies data across systems, enhancing accessibility and analysis.

• Harnesses unstructured data: The AI-driven system efficiently processes and analyzes unstructured data, leading to more accurate and consistent claim assessments.

Through a structured process we can centrally organize and integrate our data, building an ODL enables strategic initiatives such as legacy modernization and data as a service. Building this data architecture on MongoDB Atlas provides the foundation for modern apps, giving us access to new platform features such as Atlas Vector Search, which we can use to unlock unstructured data and work with AI and LLMs.

The adjuster can simply ask an AI to “show me images similar to this crash,” and a Vector Search-powered system can return photos of car accidents with similar damage profiles from the claims history database. The adjuster is now able to quickly compare the car accident photos with the most relevant ones in the insurer's claim history.

Broader applications:

While tailored for the insurance industry, this solution's principles are universally applicable. Sectors dealing with large volumes of unstructured data — from healthcare to legal services — can benefit from this approach, leading to enhanced operational efficiencies and improved decision-making processes.

Reference architectures

MongoDB Atlas combines both transactional and search capabilities in the same platform, providing a unified development experience. As embeddings are stored alongside existing data, when running a vector search query, we get the document containing both the vector embeddings and the associated metadata, eliminating the need to retrieve the data elsewhere. By leveraging Atlas Triggers, we also ensure the embedder model is triggered each time a new image and claim are added, ensuring we are always searching against the most up-to-date data. This is a great advantage for developers who don’t need to learn how to use and maintain a separate technology and can fully focus on building their apps.

With MongoDB - reference architecture:

Data model approach

The data model for the vectorized images collection is extremely basic, our claim collection contains documents including car crash photos (references to them, as AWS S3 links) and metadata about photos such as notes describing the accident and the loss amount.

Once the photos are vectorized, their embedding is added to the document as an array alongside existing fields:

Building the solution

In order to build our image search pipeline we need to follow two simple steps:

1. Configure the Atlas Search index. Create the Search index in Atlas following the instructions of this tutorial (Step 4) using the following configuration as shown in the image:

Code Snippet

2. Configure the Atlas Search index. Open the python notebook in the Github repo and follow the instructions, the code will guide you through the following steps:

• Definition of the image embedding class
• Dataset download
• Definition of data visualization functions
• Connection to MongoDB
• Vectorization of the dataset
• Querying the dataset with a photo picked by the user

Code Snippet

The above code shows how we perform the similarity query in MQL

Key learnings

• Image vectorization — The embedding generation process can be carried out using different models and deployment options. It is always important to be mindful of privacy and data protection requirements. If we need our data to never leave our servers, a locally deployed model is probably a good idea. Otherwise, we can simply call an API and get our vectors back, as explained in this tutorial that tells us how to do it with OpenAI.

• Creation of a Vector Search index in Atlas — It is now possible to create indexes for local deployments.

• Performing a Vector Search query — Notably Vector Search queries have a dedicated operator within MongoDB’s aggregation pipeline. This means that they can be concatenated with other operations, making it extremely convenient for developers because they don’t need to learn a different language or change context.

Technologies and products used

MongoDB Atlas developer data platform:

• Atlas Vector Search
• Atlas Database
• Atlas App Services

Partner technologies:

• Image embedding generation with PyTorch

Author

• Luca Napoli, MongoDB
• Jeff Needham, MongoDB
• Karthic Subramanian, MongoDB