[FirebaseAI] Add support for Grounding with Google Search #15014
Conversation
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback. |
FirebaseAI/Tests/TestApp/Tests/Integration/GenerateContentIntegrationTests.swift
Outdated
Show resolved
Hide resolved
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request introduces support for Grounding with Google Search, including new data structures and tool configurations. The changes include updates to the CHANGELOG, modifications to the GenerateContentResponse and Tool files, and the addition of new unit tests. The code appears well-structured and includes appropriate documentation.
FirebaseAI/Sources/Tool.swift
Outdated
| @@ -1,4 +1,4 @@ | |||
| // Copyright 2024 Google LLC | |||
| // Copyright 2025 Google LLC | |||
There was a problem hiding this comment.
Updating the copyright year is a good practice to keep the project up-to-date.
There was a problem hiding this comment.
nit: Since this file was renamed I think we should keep the year as 2024.
There was a problem hiding this comment.
Gemini's comment is NOT standard Google policy for existing files.
There was a problem hiding this comment.
LGTM, and will defer to @andrewheard for approval
Do all of the new optional fields need to be optional?
Separate from this PR, this feature should be added to https://github.com/firebase/quickstart-ios/tree/main/firebaseai to show an example of complying with the UI requirements.
FirebaseAI/Sources/Tool.swift
Outdated
| @@ -1,4 +1,4 @@ | |||
| // Copyright 2024 Google LLC | |||
| // Copyright 2025 Google LLC | |||
There was a problem hiding this comment.
Gemini's comment is NOT standard Google policy for existing files.
FirebaseAI/Tests/Unit/vertexai-sdk-test-data/mock-responses/developerapi
Outdated
Show resolved
Hide resolved
FirebaseAI/Tests/Unit/vertexai-sdk-test-data/mock-responses/vertexai
Outdated
Show resolved
Hide resolved
| /// undesired interaction with the rest of the page's CSS. | ||
| /// | ||
| /// To ensure proper rendering, it's recommended to display this content within a `WKWebView`. | ||
| public let renderedContent: String? |
There was a problem hiding this comment.
Do all of the new optional fields need to be optional?
-- @paulb777
I think it's likely that renderedContent will always be non-nil when GroundingMetadata.searchEntryPoint is not nil. We could consider making this non-optional.
There was a problem hiding this comment.
If we are re-evaluating mirroring the protos for this, we should make this non-optional.
Displaying a grounded result without displaying renderedContent is a violation of the service terms. To prevent this from happening, we should throw an error if renderedContent is nil.
Thoughts? @andrewheard @paulb777
There was a problem hiding this comment.
Failing early when the service terms can't be met SGTM
| /// Specifies the segment of the model's response content that this grounding support pertains | ||
| /// to. | ||
| public let segment: Segment? |
There was a problem hiding this comment.
Do all of the new optional fields need to be optional?
-- @paulb777
Based on the documentation for GroundingSupport above
Provides information about how a specific segment of the model's response is supported by the retrieved grounding chunks.
Does it make sense for a developer to ever get a GroundingSupport where segment is nil?
There was a problem hiding this comment.
Good point. It does not make sense for a developer to get a GroundingSupport where segment is nil.
This should be non-optional, and we should remove the GroundingSupport from the GroundingMetadata.groundingSupports list if it's segment is missing.
API Proposal: go/fal-grounding-api (internal)
GoogleSearchtool and.googleSearch()static initializerGroundingMetadataand related structs to store grounded results