> we don't send images to the model at query time. We describe each image once, at indexing time, with a cheap vision model, store the descriptions as text, and retrieve them alongside ordinary text chunks
This is what I've been doing in my Obsidian infodump for a while. If I know that an image is important, I generate a text description (Mermaid if possible, English if not) and paste it after the image in a block. This lets agents see the image if they don't really see it. Though my process is manual, the improvements in outcomes for agents that rely on text search/retrieval is very real and is worth it.
For a RAG project for a client with a lot of PDFs and Powerpoints with images, I used ColPali a year ago. I see the provider ColiVara is still online but it seems to have fizzled out.
Retrieving based on text and then giving the generation model the image instead is much smarter than retrieving based on image. Image-based retrieval is slow and expensive.
Same with giving the model an image vs a structured representation of it.
With media ingestion this is called "eager" processing. Historically for things like pulling thumbnails for images / video and pre-generating common sizes for things. This follows the same pattern and makes all the sense in the world. My only concern is that due to the non deterministic nature of LLMs new models will reveal new information about your data.
For example you might identify a car in an image but the context is the car running a red light. A new model might pick that up while an old one doesn't. These context adjustments might sometimes require you to rerun your LLM processing or potentially have a one to many relationship for multiple runs so you can take the best of or combine results.
Actual usage will also reveal most commonly used assets and you can target the ones that are most trafficked and save a ton on processing that way.
Reminds me of my years working on digital forensic software... Just I was working on smaller scale, but the idea was kind of similar, extract, carve, pull as many raw files as possible, then process them through various threads / pipelines of processing, then categorize and make some sort of report. I guess in this case, its get it all buttoned up for training. I have to also imagine, some of it goes through some level of human review, anyone wanting to make a worthwhile model is better off letting humans describe things, the outputs become drastically better is my understanding, sure the training can find all the patterns, but the wording to describe it all if you can get just enough detail, makes a difference.
Well I don't know if this one has been getting by others too but I have been doing this since 2 years ago and it works really well. Except the fact that for the documents I had to chunk containing these images I had to chase the authors(multiple of them) to update the relevant captions for their images.
It is cost efficient than multi-modal. Lesser ingestion time altogether. Only part is that if the retrieval query is a question which can be answered only after looking at the image, then this architecture would need some little modification.
Man I hate that AI writing tic. I appreciate the instincts for sharing the workflow. It's still very difficult to get AI to put an info dense description together though, we tend to get long and vague.
I did it a year ago for my company knowledge base we have an internal chatbot that answers with guides with images in the correct place. I did it for videos and webinars as well used Gemini to analyze videos and send people to the direct time that explains about the user question
28 comments
[ 2.5 ms ] story [ 59.0 ms ] threadThis is what I've been doing in my Obsidian infodump for a while. If I know that an image is important, I generate a text description (Mermaid if possible, English if not) and paste it after the image in a block. This lets agents see the image if they don't really see it. Though my process is manual, the improvements in outcomes for agents that rely on text search/retrieval is very real and is worth it.
Retrieving based on text and then giving the generation model the image instead is much smarter than retrieving based on image. Image-based retrieval is slow and expensive.
Same with giving the model an image vs a structured representation of it.
For example you might identify a car in an image but the context is the car running a red light. A new model might pick that up while an old one doesn't. These context adjustments might sometimes require you to rerun your LLM processing or potentially have a one to many relationship for multiple runs so you can take the best of or combine results.
Actual usage will also reveal most commonly used assets and you can target the ones that are most trafficked and save a ton on processing that way.
https://github.com/Qbix/AI/blob/6753f6e453908682401f49760002...
https://github.com/Qbix/AI/blob/main/config/observations.jso...
wrote it up here a few months ago: https://community.safebots.ai/t/building-cultural-infrastruc...
So you include colour, shapes, etc?
- Marketing material? check
- Bloated to the extreme? check
- "Get a free trial" at the end? check
- Entirely LLM generated? check
Man I hate that AI writing tic. I appreciate the instincts for sharing the workflow. It's still very difficult to get AI to put an info dense description together though, we tend to get long and vague.