aolivera → created an issue.
You could think of it like this — Google Gemini is just an LLM, and Google Vertex is a platform. To put it another way, Gemini is like the car’s engine — it can run and do things like code, analyze, generate images and videos, etc. Now, Google Vertex is more like the car itself — it’s where you install the engine (the LLMs), it’s how you steer and control it (fine-tune models), it’s where you customize it (connect to your company’s data through datastores), and it’s where you can monitor how it’s performing through dashboards.
The purpose of Google Vertex is to let businesses drive the AI engine on their own custom roads (their own data), whether that's for customer support, writing help, internal tools, and much more — all grounded in real information.
The Gemini Provider lets you connect directly to the Gemini LLM, but not to Google Vertex. The Google Vertex module, on the other hand, connects you to the full Google Vertex platform, where you can bring in your company’s data, use multiple LLMs, and choose the right tools based on your needs.
I hope this helps explain it better, it can be a little confusing :)
moved to 1.1
aolivera → created an issue.
Hey Marcus,
Thanks for the reply, after researching the major AI providers, it looks like only Google Vertex AI and Azure OpenAI currently offer native grounding via a datastore parameter. Ollama, Hugging Face, and the standard OpenAI API don’t support this out of the box.
Based on your suggestion, I scoped the new “Datastore” field so it only appears in the google vertex provider UI. Drupal’s existing form handling and config storage takes care of saving and loading the value—no changes were needed to the abstract base class.
Thanks for the feedback Scott, i have reached out to Marcus to get his thoughts as well.
Some LLM providers—most notably Google Vertex AI—offer built-in support for grounding prompts against external datastores (e.g. BigQuery tables, Cloud Storage buckets, Firestore/Datastore collections, or other HTTP-accessible endpoints). This feature is effectively a provider-managed form of Retrieval-Augmented Generation (RAG), where you tell the API “look in this datastore for relevant context before generating.”
https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/gr...
https://console.cloud.google.com/gen-app-builder/data-stores/create
How It Differs from AI Search
The AI Search sub-module in Drupal AI hooks into Search API and external vector databases (Solr, PgVector, Pinecone, etc.) to perform RAG at the Drupal layer.
Grounding via Vertex AI’s datastore happens entirely on the provider side: you simply supply the datastore identifier in your API call, and Vertex handles retrieval internally.
Example Use Case
You’re using the CKEditor AI plugin to draft content, but you want suggestions grounded in your own product catalog stored in Firestore.
In the model config you enter your Firestore path in “Datastore.”
Every time the CKEditor AI button calls the provider, it transparently includes your datastore setting—so suggestions pull live data without custom middleware.
By adding this as a first-class field in Drupal AI’s configuration, site builders get direct, provider-native grounding alongside the existing AI Search RAG capability—letting them choose whichever approach best fits their needs.
aolivera → created an issue.
Thank you valthebald,
i have removed the requested code an refactored to work with the credentials the correct way. Please let me know if you need anyting else.
aolivera → created an issue.
Removed Use statements no longer needed
Remove
use Google\Cloud\AIPlatform\V1\Blob;
use Google\Cloud\AIPlatform\V1\Client\PredictionServiceClient;
use Google\Cloud\AIPlatform\V1\Content;
use Google\Cloud\AIPlatform\V1\GenerateContentRequest;
use Google\Cloud\AIPlatform\V1\Part;
use Google\Cloud\AIPlatform\V1\PredictRequest;
Add Use statements needed
Add
use GuzzleHttp\Client;
use GuzzleHttp\Exception\RequestException;
use Google\Auth\Credentials\ServiceAccountCredentials;
Change the client to use GuzzleHtttp instead of Google Cloud
/**
* The HTTP client.
*
* (Originally this was a PredictionServiceClient; now we use a Guzzle HTTP client.)
*
* @var \GuzzleHttp\Client|null
*/
protected $client;
Change from using Prediction for client
/**
* Gets the raw chat client.
*
* This is the client for inference.
*
* @return \Google\Cloud\AIPlatform\V1\Client\PredictionServiceClient
* The Google Vertex client.
*/
public function getClient(): PredictionServiceClient {
$this->loadClient();
return $this->client;
}
To using GuzzleHttp
/**
* Gets the raw chat client.
*
* This is the client for inference.
*
* @return \GuzzleHttp\Client
* The HTTP client.
*/
public function getClient(): Client {
$this->loadClient();
return $this->client;
}
Add Helper Methods GetAccessToken and GetAuthHeaders
/**
* Retrieves an OAuth2 access token using the service account credentials.
*
* @return string
* The access token.
*
* @throws \Exception
* Thrown if unable to retrieve an access token.
*/
protected function getAccessToken(): string {
$credentialsJson = $this->loadCredentialFile();
$credentialsArray = json_decode($credentialsJson, true);
if (!$credentialsArray) {
throw new \Exception('Invalid credentials JSON.');
}
$sc = new ServiceAccountCredentials(
['https://www.googleapis.com/auth/cloud-platform'],
$credentialsArray
);
$token = $sc->fetchAuthToken();
if (!isset($token['access_token'])) {
throw new \Exception('Unable to retrieve access token.');
}
return $token['access_token'];
}
/**
* Returns the authentication headers.
*
* @return array
* An array containing the Authorization header.
*/
protected function getAuthHeaders(): array {
return [
'Authorization' => 'Bearer ' . $this->getAccessToken(),
];
}
Create Endpoint
$endpoint = 'https://us-central1-aiplatform.googleapis.com/v1/' . $url . ':generateContent';
aolivera → created an issue.