Text-Vision Retrieval Framework for Custom Knowledge Without Fine-Tuning

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing pre-trained multimodal models struggle to effectively integrate user-specific custom data, particularly in private domain knowledge settings, requiring resource-intensive fine-tuning and lacking efficient in-context learning solutions for text-vision retrieval.

Innovation Solution

A flexible and efficient multimodal text-vision retrieval framework that integrates user-specific custom knowledge without fine-tuning, utilizing a dual-branch design and customizable result ensemble strategy to support both general and custom knowledge searches.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If pre-trained multimodal models are used for text-vision retrieval, then general retrieval capability is provided, but integration of user-specific custom data is ineffective and requires resource-intensive fine-tuning

Engineering Contradiction:
Improveintegration of user-specific custom dataVSAvoidresource-intensive fine-tuning
Core Design Contradiction:
Adaptability or versatilityVSUse of energy by moving object

Solution Approach 1:

The patent introduces an intermediary component (projection layer/adaptor) that bridges the pre-trained multimodal model and user-specific custom data without requiring fine-tuning of the entire model. This intermediary enables effective integration of custom data while avoiding the resource-intensive fine-tuning process, directly resolving the contradiction between adaptability and energy consumption.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the system into distinct components: the pre-trained multimodal model handles general retrieval capabilities, while a separate projection layer or adaptor module handles user-specific custom data integration. This segmentation allows each component to specialize in its function, achieving both general capability and custom adaptability without requiring resource-intensive fine-tuning of the entire system.

Inventive Principle:
Principle #1Segmentation

2Reliability

If fine-tuning is applied to integrate custom data, then user-specific knowledge is incorporated, but computational resources and time are significantly consumed

Engineering Contradiction:
Improveuser-specific knowledge integrationVSAvoidfine-tuning time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts only the necessary components for custom data integration (projection layer, adaptor) from the full fine-tuning process. By taking out just the essential elements needed to incorporate user-specific knowledge, the system achieves reliable custom data integration while dramatically reducing the time and computational resources required compared to complete model fine-tuning.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent performs preliminary actions by pre-training the projection layer or adaptor on user-specific custom data before deployment. This preliminary integration of user-specific knowledge allows the system to achieve high reliability in custom data handling without requiring time-consuming fine-tuning during actual operation, as the adaptation is already accomplished in advance.

Inventive Principle:
Principle #10Preliminary action

3Device complexity

If a unified model is used for both general and custom knowledge, then model simplicity is maintained, but performance on custom domain tasks deteriorates

Engineering Contradiction:
Improvemodel structureVSAvoidcustom domain retrieval accuracy
Core Design Contradiction:
Device complexityVSManufacturing precision

Solution Approach 1:

The patent applies local quality by making different parts of the system serve different functions: the pre-trained multimodal model maintains simplicity for general tasks, while the added projection layer or adaptor provides specialized handling for custom domain tasks. This local differentiation ensures high accuracy on custom domain retrieval without significantly increasing overall model structural complexity.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent adds another dimension to the model architecture by introducing a projection layer or adaptor that operates in a separate computational space. This dimensional addition allows the system to handle custom domain tasks with high precision while keeping the original multimodal model structure relatively simple, effectively resolving the contradiction between complexity and precision.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

4Adaptability or versatility

If resource-intensive fine-tuning is performed, then custom data integration is achieved, but computational cost and energy consumption increase

Engineering Contradiction:
Improvecustom data integration capabilityVSAvoidcomputational energy consumption
Core Design Contradiction:
Adaptability or versatilityVSLoss of energy

Solution Approach 1:

The patent employs a lightweight projection layer or adaptor that acts as a disposable or easily replaceable component for integrating custom data. This cheap component achieves effective custom data integration without the high energy consumption of fine-tuning the entire model, directly addressing the contradiction between adaptability and energy loss by using a computationally inexpensive solution.

Inventive Principle:
Principle #27Cheap short-living objects (Disposable)

Data Source

PatentUS12475163B2Method and system for a text-vision retrieval framework
Publication Date: 2025.11.18 DELL PROD LP
  • US12475163B2 patent drawing
  • US12475163B2 patent drawing
  • US12475163B2 patent drawing

AI summary

A method for managing a framework includes: receiving, by a GUI, a query that is sent to a first module; analyzing, by the first module, the query to infer intention; making, by the first module, a determination that the intention is not searching for an object in a database; sending, by the first module, the query to a second module; transforming, by the second module, the query into a vector that is sent to a third module; performing, by the third module and using the vector, a search for a nearest image in the database; identifying, by the third module, a path associated with the nearest image, which is sent to an analyzer, in which the analyzer further sends the path to a fourth module; and fetching, by the fourth module and based on the path, an image from a store, which is sent to the GUI.