Adobe Patents a Proofreader That Checks an AI's Database Searches Before Running Them
Ask an AI a question about a database and it can write a search so garbled that it asks for movies that acted in actors. Adobe's patent adds a checker that catches the mistake and sends the search back for a rewrite.
What Adobe's AI database proofreader does
You type a plain question into a company chatbot: which actors were in this movie? Behind the scenes, an AI turns your sentence into a formal search that a database can run. Sometimes it flubs the translation, and the search ends up asking for movies that acted in actors.
Adobe's patent describes a checker that sits between the AI and the database. It reads the AI's search, compares it with what the database actually contains, and flags anything that doesn't exist or points the wrong way. The error goes back to the AI, which tries again.
Only a search that passes gets run. Your answer then comes back in plain sentences, and if the search finds nothing, the system can suggest a similar term you might have meant.
receiving, by a processing device from a large language model (LLM), a graph query generated by the LLM based on a natural language query (NLQ); receiving a modified graph query from the LLM based on an error identified in the graph query; …
Translation: The system catches a mistake in the AI's database search plan and asks the AI to fix it.
How the checker catches a backwards search
The filing covers how a large language model (LLM, the type of AI behind modern chatbots) turns a natural language question into a graph query, a formal search written for a knowledge graph. A knowledge graph is a database that stores things like people, movies or customers as dots, and the relationships between them as arrows.
A validation module then parses the query and compares it with the graph. The description lists several checks:
- Does each relationship in the query actually exist in the graph?
- Does the arrow point the right way (an actor acts in a movie, not the reverse)?
- Do the properties named for each entity really belong to it?
When the checker finds a problem, it sends the error back to the LLM, optionally with the graph's schema (a map of what the database holds) and the user's earlier chat history. The claims also have the system count how many times a query has been rewritten, and the description gives a limit of three as an example.
If a valid query returns nothing, the system turns the search term into an embedding (a numeric fingerprint of its meaning), finds the closest match, and asks the user whether to re-run with it. The filing's example offers a term called 'TEST HTTP destination'. Retraining the LLM on the errors is described as an option.
A validation module identifies an error in the graph query. The query management module provides an indication of the error to the LLM. The query management module receives a modified graph query from the LLM.
Translation: A checker program points out what went wrong so the AI can rewrite its search request properly.
Why a retry limit matters for AI answers
If you have used a chatbot that answers questions from a company's own data, you have probably seen it return something wrong or nothing at all. The filing says bad searches like these normally need a lot of cleanup afterward. A built-in check could mean fewer wrong answers and fewer dead ends for you.
The filing also pitches this as a cheaper route than heavy manual tuning of the AI, and says it can cut the computing time spent on bad searches. It names no Adobe product, so treat it as a technique that could sit behind any question-answering tool built on a structured database.
Adobe's sixth filing we've tracked since July in our AI models working in teams builds on earlier applications like one where AIs grade each other and description into a finished page.
Nothing here needs new hardware. It is software wrapped around parts that already exist: a chatbot, a database and a handful of simple rules.
The checks themselves are ordinary. Does this relationship exist, does it point the right way, does this property belong to this thing. A team that already has a chatbot on top of a structured database could add that step in front of the database without retraining anything.
What has to exist first is the database itself, organized as a graph with a written map of its contents. A company without one would have to build it before any of this helps. The retry cap has a practical job: it keeps a confused AI from looping forever. Retraining on the errors is the heavy, optional part, and the shortest route to a working feature skips it.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time Adobe patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
14 drawing sheets from US 2026/0349995 A1 · click any drawing to enlarge
Show the other 6 sheets
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in