Dr. Alexander Kihm is the Founder and Chief Scientist of a Berlin-based context intelligence lab called POMA AI.
To start, could you tell us a little about yourself, your background and what led you to work in AI?
I’m Alexander Kihm, founder and CEO of POMA AI in Berlin. I trained as an industrial engineer at the Karlsruhe Institute of Technology and did my PhD in big data econometrics at the German Aerospace Center, where I worked on the development of the world’s first plug-in hybrid car for the mass market. Since then I’ve been a serial founder: Fairr, a fintech that digitised Germany’s pension system and was acquired by Raisin, and Advo-Assist, which became Germany’s largest digital platform for lawyers.
What pulled me into AI was a very unglamorous observation: the models were getting dramatically better every few months, but the answers companies got out of them on their own documents were not. When you trace those failures back, the model is rarely the culprit. The problem sits upstream, in how documents are cut up, described and stored before the model ever sees them. That plumbing is where I decided to spend my time.
For readers who may not be familiar with POMA AI, what does the company do, what problem are you trying to solve and what is your role at POMA AI?
POMA builds retrieval infrastructure for AI systems and agents. In plain terms: when an AI assistant needs to answer a question from a company’s own documents, something has to find the right passage, table or figure first. That step is retrieval, and it fails far more often than people assume.
Our core product is an ingestion engine that turns long, messy documents (reports, manuals, contracts, scanned forms) into pieces that keep their place in the document: which chapter, which heading, which table they belong to. A number on page 40 means nothing on its own; it means a lot once you know it sits under “Q3 payroll, Berlin office”. We preserve that context so search finds the right thing.
I’m the founder and CEO, and I also act as CTO and chief scientist, so besides running the company I set the technical direction and spend a lot of my time on research, including the benchmarks we publish openly.
Why is image retrieval such an important part of making AI useful in the workplace, particularly when documents like technical manuals, architectural blueprints and medical scans contain information that isn’t captured in text?
Because in many industries the image is the document. A maintenance manual explains a valve assembly with an exploded diagram, not three paragraphs. An architectural plan carries dimensions, room labels and load notes that exist nowhere else. A scanned bank form holds the account holder’s date of birth as pixels, not text.
If your AI system only searches text, all of that is invisible. Employees then learn that the assistant “doesn’t know” the very things they most often need, and they go back to scrolling PDFs by hand. Getting images right is what turns an AI assistant from a nice demo on clean prose into something an engineer, architect or clinician will actually rely on.
Why do AI systems often struggle to retrieve the right image?
Most systems search images by turning each one into a single vector, a compressed numerical summary of the whole picture. That summary captures the gist well and the specifics badly. It’s a bit like looking at a page through frosted glass: you can tell it’s a financial table, but you can’t read the figures.
You see this in the classic “red car” problem: search for a red car and you also get red things that aren’t cars and cars that aren’t red, because the system matched on the concepts loosely rather than on what the image actually shows.
It gets worse with exact details. In one of our tests we asked for a specific payroll figure, 852.79. Image-based search ranked a US Treasury bulletin page first and the actual payroll page fifth. Both pages look like “a page of numbers”, so to the image model they were close neighbours. For a date of birth on a bank-transfer form, the right page also came fifth. When we searched over detailed descriptions of the same pages instead, both correct pages came first.
Fifth sounds close, but an AI agent that reads only the top result will confidently answer with the wrong number.
How much does context matter when an AI system is trying to understand an image, and why might details such as captions, labels and the surrounding text be essential to interpreting it correctly?
Enormously. Take a zoomed-in X-ray of a bone. Without context it’s an abstract pattern of black, grey and white; even a trained person needs to know which bone, which view and why it was taken. The caption (“left distal radius, lateral view, two weeks post-fracture”) and the surrounding text describing the injury are what give the image its meaning.
The same holds for a chart without its axis labels or a floor plan without the title block that says which building and which floor it is. Image pixels tell you what something looks like; the context tells you what it is and why it matters. Without that, retrieval either pulls up too much (every X-ray looks like every other X-ray) or too little (the one you need never matches the question).
How do detailed visual descriptions, including text extracted from images, help AI systems find the right information? What makes a description genuinely useful for accurate retrieval?
A good description turns a fuzzy picture into precise, searchable language. If you think of search as pointing at content, a vague description is a broad beam and a good one is a laser aimed at exactly that figure.
In our experience a genuinely useful description has four parts:
- What is actually shown, concretely: “exploded view of a hydraulic pump with seven numbered components”, not “a technical drawing”.
- Every piece of text in the image, transcribed exactly: labels, part numbers, figures, dates. Image models do pick up some text, but loosely, so a search for the exact label you remember can miss. Transcribed text matches exactly.
- The original caption, which is often the author’s own summary of why the image is there.
- Where the image lives: which document, chapter and heading it sits under.
That last part is the one most systems skip, and it’s often the one that separates two otherwise identical-looking pages.
You’ve highlighted the importance of preserving document structure and context during data ingestion. Why is it so difficult to fix retrieval problems later in the process, and how does a context tree help?
Because information that is thrown away at ingestion cannot be recovered later. Most pipelines start by chopping documents into fixed-size chunks and pulling images out as loose files. At that moment the figure loses its caption, the table loses its header, and the paragraph loses the heading that explained what it was about. Everything downstream (rerankers, bigger models, clever prompts) is then trying to reconstruct meaning from fragments. That’s why so many attempts to fix retrieval have disappointed: they intervene too late.
A context tree keeps the document’s skeleton intact. Every piece of content, including every image, carries its path: document, chapter, section, sub-heading. So the system doesn’t just store “a table containing 35”; it stores “35, under International Capital Movements, in the 2023 Treasury Bulletin”. That path is what tells two similar-looking items apart.
We tested this on over 21,000 chunks. Adding that hierarchical context moved the correct answer from a median rank of around 1,780 to around 15, a roughly 119-fold improvement. The common assumption is that extra context “dilutes” a search vector. In practice it disambiguates it.
Why might a smaller, more specialised model be better suited to generating visual descriptions than a large general-purpose model, particularly when businesses need to balance accuracy, speed and cost?
Describing images for retrieval is a narrow, repetitive job done at enormous volume. A company might have millions of pages, each with several figures. Running a frontier general-purpose model over all of that is slow and gets prohibitively expensive quickly, and you pay for capabilities (poetry, coding, general chat) that this task never uses.
There’s also a quality argument. The model should see the “Goldilocks” amount of information: the image, its caption, the nearby text and its place in the context tree. Not too little, or it guesses; not the whole 300-page document, or it gets distracted and costs a fortune. A smaller model trained for exactly this, fed exactly that slice, is faster, cheaper and more consistent. It can also run on a company’s own hardware, which matters a great deal for medical, legal or engineering documents that can’t leave the building.
That’s the approach we’ve taken with our on-premises product. It runs a single small model, around 4 billion parameters, on one standard GPU inside the customer’s own infrastructure, fully disconnected from the internet, so documents never leave the building. On top of it we train lightweight specialisations for specific jobs, one of them dedicated to describing images, charts and figures in documents. In our own tests, our small specialised model describes images at least as well as general-purpose models up to a hundred times its size. And because it’s small, we can go a step further and adapt it to a client’s own domain and documents, whether that’s engineering drawings, medical imagery or financial forms, which makes it better still. You don’t need the biggest model; you need the right one for the job.
Looking ahead, how could better image retrieval and more context-aware search change the way businesses use their existing data and AI agents? What should companies be thinking about if they want to get more value from the information they already have?
Most companies already own the answers to a large share of their questions. They’re buried in manuals, drawings, scanned forms and slide decks that nobody can search properly. Better retrieval doesn’t create new data; it makes the data you have reachable, which is usually the cheaper and faster win.
This matters even more with AI agents, because agents search differently from people. A person runs one search, skims the results and uses judgement. An agent may fire off dozens of queries in a loop and act on whatever comes back first. If the right figure sits at rank five, a human might spot it; an agent often won’t. We’ve written more about how agents search at https://www.poma-ai.com/brief.
My advice to companies is three things:
- Audit what’s locked in images. Diagrams, scans and charts are often where the most valuable, least searchable information sits.
- Fix ingestion before buying a bigger model. Preserve structure, captions and context at the start; you can’t add them back later.
- Test retrieval on its own. Ask real questions with known answers and check whether the right source comes back first, not just whether the final answer sounds plausible.
The organisations that get this right will find their AI agents suddenly “know” a lot more, not because the model got smarter, but because it can finally see what was there all along.
