[Agent] SimilaritySearch in Azure Search has no `id` in hits

[apfelbox]

Hi,

so we are currently trying out the new bundles and they work really great so far! Nice job!

However, we found an issue and are unsure on how to proceed.

As context: we use Azure-based ChatGPT with Azure Search-based embeddings (RAG).

So we fetch the chunks for the request from Azure Search, however it currently breaks: the structure of the values in the result look like this:

[
	"@search.score" => "...",
	"chunk_id" => "...",
	"parent_id" => "...",
	"chunk" => "...",
	"title" => null,
	"text_vector" => "...",
]

However, this currently breaks, as the SearchStore tries to access id in this array:
https://github.com/symfony/ai/blob/main/src/store/src/Bridge/Azure/SearchStore.php#L92

And we don't have an id.

So my question: is that something we need to configure on our side or is the assumption in the code currently wrong, that there always is an id?

Comments:

• Neither chunk_id nor parent_id are in any way Uuid-compatible
• When we change the line to Uuid::v4(), it appears to work

Thanks for any pointers and for the great bundles

[chr-hertel]

Hey, it's been a while since I played around with that store. How's the data getting into that store? with built-in indexer of Azure?

I think we have two options here:

1. force users to have an ID as UUID in their schema (doesn't sound ideal)
2. make ID column configurable, like mapping chunk_id to it + open up the type declaration
3. drop the ID on our end completely and rely on users handling that themselves with the metadata

@OskarStark were you using Azure AI Search as well? what's your take here

[OskarStark]

My take was, that I entered the data via our store, I guess that's not the case here, am I right @apfelbox ?

In fact this is something we already discussed (with no result) with @alcaeus: "How can we retrieve data with a different indexed format aka. how can we make project objects indexable for our stores."

@apfelbox do you have an idea in mind how to fix this? We could change the contract, we could make it configurable via options etc.

[apfelbox]

I am actually not sure on how we index the data right now (as we are currently experimenting with everything quite a lot), however I am pretty sure that we just put a set of markdown file into an Azure Storage bucket and push it through the indexer.
The indexer then chunks it, calculates necessary overlap, etc.. and that's what we get in the search endpoint.

@OskarStark I am actually not sure. I tried to find out what the VectorDocument::$id is used for, but couldn't find anything definitive (it was a long work day, so maybe I overlooked something). So maybe it is fine to just create new ones as a fallback / via an extension (like transformers / event / etc)?

In our case just creating fresh Uuids worked, however that might have been a coincident. Reusing anything from the actual return value from the search seems impossible for our case, as nothing in the hits is in any way uuid-compatible.

[chr-hertel]

I tried to find out what we use the VectorDocument::$id for, but couldn't find anything definitive
I think that might actually be true - need to check the apps i have

I currently favor number three here:

drop the ID on our end completely and rely on users handling that themselves with the metadata

I remember that you can explicitly configure the schema that Azure Search uses - not sure for the default indexer tho.

[OskarStark]

I remember that you can explicitly configure the schema that Azure Search uses - not sure for the default indexer tho.

Yes, but I couldn't find a way to do it programmatically in the past with the initialize method. That's the reason I switched to MongoDB

[apfelbox]

@chr-hertel what is the ID currently used for?

Because it could either be dropped or (depending on the usage) be added in some form of extension point, that would be sitting between fetching the data from azure and generating the internal structures.