Customized Grounding "Vertex AI search" - where to get path?

[Aftermath5428]

So, when you create a multimodal conversation you have the possibility to customize your grounding. You can either pick google search which is OG search, or a “Vertex AI datastore path”. The path should follow the following format:

projects/{project_id}/locations/{location}/collections/{collection_name}/dataStores/{datastore_name}

But where do I set up this datastore path? And where can I copy it from so that I don’t have to use my precious fingers to type?

Or are they asking for the path that can be set up in “Agent Builder”? And if yes…why can’t I have a select button?

I am a bit confused.

And what is the difference between Agent Buider and the different flavors of “chats” in Vertex AI?

[ruthseki]

Hi @Aftermath5428,

Welcome to Google Cloud Community!

To generate a datastore path with format:

projects/{project_id}/locations/{location}/collections/{collection_name}/dataStores/{datastore_name}

First, you need to create a Datastore from Agent Builder and get the datastore_name and location details. Below is the screenshot for your reference:

Then, replace project_id with your GCP project id and collections is default_collection unless you specify.

Here’s an example of datastore path:

projects/test-sandbox-seki/locations/global/collections/default_collection/dataStores/datastore_test

In addition, there’s no feature yet to directly select or copy the datastore path within Agent Builder. However, upon checking, there’s already an existing internal discussion for this functionality. Though you can still file a Public Feature Request to display the datastore path for grounding with a copy or select button on the data store list page or to let you customize your grounding with the Vertex AI Search using your preference so that our Engineering Team can look into it. Also, this way you could have visibility on the progress of your request as it is publicly available. Note that there’s no definite date as to when this will be implemented. For future updates, I suggest keeping an eye out on the issue tracker and release notes.

With regard to difference of Agent Builder and other chat services in Vertex AI, here’s a breakdown of the different options:

Agent Builder is a development tool. It allows programmers to create conversational AI agents, also known as chatbots. Developers can define the goals for their agent, provide step-by-step instructions, and train the agent on conversation examples. Agent Builder can be used to create chatbots for various purposes, like customer service, information assistants, or educational tools.

Gemini is a language model within Vertex AI that excels at providing human-like responses in chat applications. It’s designed for natural language understanding and can be used to build chatbots, virtual assistants, and other conversational systems. The following model supports chat tasks: Gemini 1.5 Flash (Preview), Gemini 1.5 Pro (Preview) and Gemini 1.0 Pro.

Vertex AI SDK offers a more programmatic approach to building conversational agents. You can use this SDK to create custom agents and integrate them into your applications. The SDKs support use cases like building stateful multi-turn conversations (chat). The SDK gives you more control over the entire process, including how the agent is initialized, how it interacts with users, and how it handles responses.

Vertex AI PaLM 2 for chat is fine-tuned for multi-turn chat, where the model keeps track of previous messages in the chat and uses it as context for generating new responses. Supported model is chat-bison.

I hope the above information is helpful.

[Aftermath5428]

Thank you!
Just a quick follow up.

Is there a way to store the result from a multimodal search to a data store / vector db for later retrieval by another agent like bot?

So can I set up the following flow:

Vertex AI Multimodal Bot —> Request grounded with Search —> save result to vector storage —>> another bot from Agent Builder that combines multiple storages ?

if so…how? Can’t seem to find the full documentation

thx

[iampatgrad]

There needs to be a way to get to the full path. there is no way for me to know what “collection” my app/datastore is in. “default_collection” is a ridiculous magical string. I’m not an Org admin, so I can’t see this.

[Andrew_B]

Magical… I like that. There may have been plans to add support for custom collections, but as of now “default_collection” is static:

projects/{project}/locations/{location}/collections/default_collection/dataStores/{datastore}

[tommy-botenders]

When using this path associated with my datastore, I’m getting errors interacting with the chatbot. "ERROR Request contains an invalid argument. "

using this path: projects/{project}/locations/{location}/collections/default_collection/dataStores/{datastore}

Why is this?

[sahilnaircool]

The error you’re encountering, “Request contains an invalid argument,” could be due to several possible issues with the path or the configuration when interacting with the chatbot. Here’s a checklist to help troubleshoot:-

1. Path Format

2. Invalid datastore ID

3. Missing Required Parameters

4. Authentication

5. Collection Configuration

6. API Version

7. Invalid Location

[alexpineda19]

For some reason I get the following error. I know %100 sure, everything is set as it has to be, any insights into why this might happen?

[Mustafa_Gulerca]

The provided answer is unclear and could be misleading, especially for datastores that use a storage bucket as a data source.

In my case, my datastore path was:

datastore: 'projects/<project_id>/locations/eu/collections/default_collection/dataStores/gclouds-sales-data_gcs_store'

It took multiple trial-and-error attempts to determine the correct path.

The datastore name highlighted in the red rectangle was not helpful because it refers to the collection name, not the datastore name. In fact, you must use “default_collection” as the collection name ( even you have your own); otherwise, it won’t work.

And the datastore ID is under the “Entity”.

I believe the current implementation lacks clarity, and a more standardised approach is needed to accommodate all use cases effectively.