The record your AI search missed: start with the indexed text

Open a record on the work screen and you see a cause memo: “The cover was damaged when the book was crushed in the return bin.” Now suppose that when you ask the agent to “find inquiries about damaged books”, it misses this record. A person reads the memo and knows the record is relevant. The first thing to check is whether the same sentence was ever handed to the search tool the agent uses.

I ran into a problem like this while working on the search tool of an internal bot built with ADK Java. An inquiry record is not complete the moment it is created. The person who files it writes only a title and a description; the cause they investigated and the action they took are written later, by the person handling it, in other fields. The search configuration did not include those memos. The library and the field values in this article are a made-up example that stands in for the real work.

There are two things to check. Is this sentence used when searching? After the record is found, is this sentence given to the model? Fixing the first does not necessarily fix the second. This article walks through the actual change that merged the text, the limit of a prefix excerpt, and a search evidence lab where you can change the settings and see where the same sentence drops out.

The inquiry and the outcome end up in different fields#

The inquiry as first filed only asked, “please check the condition of the book.” The person handling it added a cause and an action while processing the record.

A search tool that reads only the title and the description gets the explanation from the time of filing. To use the later findings — the damaged cover, the padding check that actually happened — those memos have to be part of what is searched. The fact that the fields exist in the source database does not satisfy that condition on its own.

This is not about one particular word. Semantic search may well decide the record is relevant even without “damaged cover” in the text. But if the cause sentence the staff member confirmed is never used in search, the information in that sentence never gets a chance. Whether a document can be found and whether a specific piece of evidence can be used in search are two different questions.

The search service and the model receive different data#

In this case, structured records were loaded into a managed search service, then called Vertex AI Search. The current name in the official documentation is Agent Search, and that is the name used here. The search tool did not read every field of the work screen on each question; it queried data that had been loaded in advance and marked for searching.

At load time you select the text to search from the source. When a question arrives, the search service picks the relevant documents, and the application picks the fields it needs from those results and sends them to the model. The cause memo can drop out at two points in this flow: it was never part of the searchable text, or it was left out when the found document was turned into the response.

In Agent Search these settings are checked separately. The names look alike, but they change different things.

A text field with no key property can still have searchable turned on. indexable is a separate setting used for filters, boosting and facets, so its name alone says nothing about full-text search. Fields mapped to key properties are indexable and searchable by default and get a higher weight, but the field returned as raw text and the application code that passes it along still have to be checked on their own. Configure field settings (opens in a new tab) · Provide a schema (opens in a new tab)

Say the cause memo is used for search but not returned. The search service can consult the memo when picking the record, but a model that receives only the title cannot see the cause of the damage in “Returned item condition check request”. That is why finding the record and having the evidence for an answer are two different successes.

Adding the cause and action memos to the description#

Before the change, the title was mapped to title and the description to description. The cause and action memos had neither a key-property mapping nor a Searchable setting.

When I tried to map both memos to description, the console refused with an error about multiple mappings — I saw that directly. So the search view merged the three fields into one, and that one field was mapped as the description body. The configuration below is an example that carries no real work data.

Before
description ← "Please check the condition of the returned book"

After
description ← SEARCH_TEXT
Inquiry: Please check the condition of the returned book
Cause: The cover was damaged when the book was crushed in the return bin
Action: Adjusted the pickup schedule and checked the padding

The title stayed mapped to title. While merging the text, leftovers such as HTML tags were cleaned up too. What changed in the example is the description given to the search service: before, it held only the filer’s request; after, it also holds the cause and the action the staff member confirmed. The “Inquiry / Cause / Action” labels above are there to make each sentence’s origin easy to read; they are not a copy of the actual storage format.

Looking at it now, another option is to keep the cause and action memos as separate fields and turn Searchable on for each. Merging gives you one searchable body to build and return. Separate fields let you configure search and return for the cause and the action individually. Which one finds records better has to be compared with the same questions and records, and in this case the two were not measured against each other. Nor does this mean the merge was chosen with key-property weighting in mind.

The refused multiple mapping is what the console did at the time. In the field settings, schema provision and schema update documents checked on September 15, 2026, I found no stated limit on the count. So it cannot be generalized that other systems must merge the text. Decide which fields are needed and who may access them, choose a configuration, and then confirm it in the loaded documents and the schema. Changing the source view alone does not mean the search service is using the new text.

The evidence sentence has to survive after the search#

Widening the search says nothing about whether the model gets to read the content. At the time, the tool already had two remedies: expanding the query into several phrasings and raising the number of results. When the larger result set was passed to the model, only a few summary fields were kept — and that response had none of the staff member’s cause or action memos.

So the first 200 characters of the merged text were added as an excerpt field in the response. It keeps the search result short while still giving the model part of the text. The merged text and this excerpt are the design still in use today.

With the short inquiry above, the cause and the action both fit inside 200 characters. Now suppose the description contains a long account of how the book was returned and what should be checked. The merge order is the same, but the cause memo is pushed further back. The excerpt length stays the same; the position of the sentence you need moves.

In the second case the cause sentence is still in the search text. Once this record is in the results, raising the number of results cannot repair the excerpt of a record that has already been returned. You have to look at what the application puts into the final response. This table is a counterexample for explanation; it is not a reproduction of the same failure in the current system.

Once the omission is confirmed, the options include returning the specific cause and action fields the answer needs, excerpting the part related to the question, or reading more through a detail lookup. Increasing the excerpt length is also an option, but the next record may be longer still. Rather than sending the full text of every record unconditionally, decide both which evidence the question needs and how much may be returned. None of these alternatives were applied to the current system or compared for performance.

Try it: follow the same evidence sentence to the end#

The lab below uses the single made-up record from above. The record is fixed as being in the search results, and the lab only computes how far the cause sentence travels as you change the text composition, the field return and the excerpt. It does not imitate a real search engine’s matching or ranking, nor the model’s answer.

Start at gate 1, Include the memos in the search text, and choose “include”. The sentence from the source record now appears in the search text and in the model input. With that in place, turn on Make the inquiry long: the sentence stays in the search text but disappears from the 200-character excerpt. At gate 3, increase the excerpt length or pick the line containing “damaged” and see what changes. The line selection is a string rule that exists to show the difference; it does not reproduce any product’s semantic excerpt feature.

If you choose “don’t return it” at gate 2, no excerpt method can bring the cause sentence back. That is when the returned fields come before the excerpt. Even when the cause sentence survives to the end of the lab, what has been confirmed is delivery of that sentence. Whether the model actually uses that evidence well is something to check in the real answer.

With real data, pick the missing step first#

To investigate the same symptom in your own system, pick one record ID you consider relevant and one sentence that is the basis for that judgement. Do not read only the model’s final answer; put the search service’s original response and the tool response sent to the model side by side. Keeping the two responses apart is what tells you whether a field was missing from the service or dropped by the application.

In this case the way results from several queries were merged also changed: from sorting by the maximum returned score per document to RRF, which uses each list’s rank. That is a change to how documents are ordered across several lists. A cause memo getting cut from the response of an already selected document has to be fixed separately. Evaluating both changes at once makes it hard to tell which one moved the result.

Once you have chosen the step to fix, compare before and after with the same question, filters and target record. If the loading or the schema changed, check after the search service has picked it up. Record the time the source was modified and the time the search results were observed, so that a change that has not propagated yet is not mistaken for a failed fix. The relation between schema changes and re-indexing is described in the schema update documentation (opens in a new tab).

Checking only the question that was missed at first can hide changes in other questions. Compare the questions that used to work as well, and keep the record IDs and ranks, the delivered evidence sentence and the actual answer as separate notes. What matters is not to fold “the record was found” and “the answer used that evidence” into a single success mark.

What this article covers is an implementation change from August 2026; how much the search quality improved after it was not measured. What you can take from it is the diagnostic method. Open one missed record, look for the very sentence that made you call it relevant in the search text and in both responses, and you narrow down the settings and code to check next.

References#

The field settings and schema documents were re-checked on September 15, 2026. Product specification, the implementation and observations at the time, and the made-up lab are kept apart.

• Agent Search product overview and naming (opens in a new tab)
• Agent Search field settings (opens in a new tab)
• Providing a schema and field defaults (opens in a new tab)
• Updating a schema (opens in a new tab)
• How RRF merges rankings (opens in a new tab) — a reference for the algorithm; it does not mean Azure AI Search was used in this case.