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 retrievaland 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.

Reference Architectures

MongoDB Atlas combines 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. This is a great advantage for developers who don’t need to learn to use and maintain a separate technology and can fully focus on building their apps.

Figure 1. Reference architecture with MongoDB.

Figure 2. A dataset of photos of past accidents is vectorized and stored in Atlas.

Figure 3. An image similarity query is performed, and the 5 top similar images are returned.

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:

{
   _id: ObjectId('64d39175e65'),
   notes: "The crash happened...",
   loss amount: 1250,
   filename: "image_65.jpg",
   url: "https://my-bucket...",
   embedding: [0.3, 0.6, ..., 11.2]
}

Sample document after the image embedding is added.

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:

{
   _id: ObjectId('64d39175e65'),
   notes: "The crash happened...",
   loss amount: 1250,
   filename: "image_65.jpg",
   url: "https://my-bucket...",
   embedding: [0.3, 0.6, ..., 11.2]
}

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

documents = coll.aggregate([
   {
      "$search": {
      "index": "default",
      "knnBeta": {
      "vector": query_embedding,
      "path": "embedding",
      "k": 5
         }
      }
   }
])

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

Figure 4. How to configure the Search Index in the Atlas UI.

Visit the GitHub repo: Insurance-image-search and create this demo for yourself by following the instructions and associated models in this solution’s repository.

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

Authors

• Luca Napoli, MongoDB

• Jeff Needham, MongoDB

• Karthic Subramanian, MongoDB