Skip to content

feat: basic support for Google Gemini models #215

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

onemoreangle
Copy link
Contributor

Added visitors to more flexibly handle how messages are transformed into a request body and implemented an initial Google provider supporting basic text generation with it

…nto a request body and implemented an initial Google provider supporting basic text generation with it
@chr-hertel
Copy link
Member

Hello @onemoreangle - what an entry to the repository! Thanks for your contribution! :)

I thought already about the different body formats for different models and this is def something we need to work on - thanks for tackling that!

I will give it more detailed look this evening, but first question would be: did you consider to use Symfony Serializer?

{
public const GEMINI_2_FLASH = 'gemini-2.0-flash';
public const GEMINI_2_PRO = 'gemini-2.0-pro-exp-02-05';
public const GEMINI_2_FLASH_LITE = 'gemini-2.0-flash-lite-preview-02-05';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to replace those explicit dated version strings with latest tag? I have no key to try it but i am curious from the documentation.

https://ai.google.dev/gemini-api/docs/models/gemini?hl=en#model-versions

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will check this out later!

If you have a Google account you can actually get an API key for free, in case you're interested.

Copy link
Contributor Author

@onemoreangle onemoreangle Feb 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to replace those explicit dated version strings with latest tag? I have no key to try it but i am curious from the documentation.

https://ai.google.dev/gemini-api/docs/models/gemini?hl=en#model-versions

Alright, I've checked, these seem to be specific previews right now, because neither using latest nor without tag works for these models. Would you want these removed and only list the stable models and latest models that do work?

Latest could point to preview models, so if it's going to point to that it should probably be transparent

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just suprised over the dates in the versions. OpenAI has them too but also high level naming for the "latest". Wondered why this should not be possible with Google Gemini. So many thanks for checking!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just suprised over the dates in the versions. OpenAI has them too but also high level naming for the "latest". Wondered why this should not be possible with Google Gemini. So many thanks for checking!

Yes it is strange, based on their description I would have assumed it would be pointing to there as well. I read it a bit more thoroughly and checked gemini-2.0-pro-exp and that does work, so looks they just don't consider it ready yet :)

@onemoreangle
Copy link
Contributor Author

Hi @chr-hertel! Thanks for your work on this repository, came across it yesterday and am excited to play around with it. I was looking to compare some LLMs with regards to text and while playing around I noticed Google wasn't directly supported, which was a bit of a bummer because they provide free API with lower rate limits.

I tested quickly if I could implement this and noticed it wasn't going to work with the current way of serializing because the hierarchy was quite different. Not just the nodes itself. So for full flexibility I opted for a visitor pattern but I haven't looked well into Symfony serializers. Are they as transparent when you have to change the hierarchy?

@onemoreangle
Copy link
Contributor Author

onemoreangle commented Feb 18, 2025

I'll add a bit of context; the main reason for choosing the visitor approach is because we need to traverse the tree of messages from the outside because this is where the implementation details lie. While looking for a way to generalize it even more, I came to the conclusion that since the request method is responsible for transforming the MessageBag into a request body, and it's an interface implementation, we have no easy generalizable way to do this.

With regards to Symfony; I think serializers like that are powerful because they operate on the classes automatically and allow modifications to the structure by annotations/attributes, but we cannot do this at the place we want to. In other words, if we were to use this we would probably end up writing lots of instanceof checks, in which case we would have benefited from this approach anyways.


use PhpLlm\LlmChain\Model\LanguageModel;

final readonly class GoogleModel implements LanguageModel
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would favor to call this just Gemini - WDYT?

Suggested change
final readonly class GoogleModel implements LanguageModel
final readonly class Gemini implements LanguageModel

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes good point, maybe both. There is also Gemma. So maybe GoogleModel as a parent so we only need one instanceof check in the Handler?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, sounds fair - depends a bit on the difference Gemma would need in request/response handling, but if there's a synergy that's a good point 👍

Copy link
Member

@chr-hertel chr-hertel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I had a deeper look and I'm quite convinced that we can solve this without extending the message classes.

there is no reason the data classes need the dependency to a ContentVisitor other than using that pattern.

Please have a look at the LlamaPromptConverter which solves a similar issue but isolating the conversion in its own scope. which makes it also quite easy to test.

From a functional point of view the example works well and I'd love to merge this after revert in model and platform namespace.

@onemoreangle
Copy link
Contributor Author

onemoreangle commented Feb 18, 2025

So I had a deeper look and I'm quite convinced that we can solve this without extending the message classes.

Thanks for taking a deeper look! I agree that we could but I do think the visitor approach is a good fit here.

there is no reason the data classes need the dependency to a ContentVisitor other than using that pattern.

Yes, but it is an established pattern to specifically separate algorithms from data classes, for a use-case such as this. It enforces compile-time safety by making us handle new message types when they are introduced. There is also separation of concern based on the message type and deduplication of logic in the instanceof checks of Message and Content subtypes.

Could you explain to me how it would make testing harder? I genuinely don't understand as the logic is even more isolated.

Ultimately it comes down to whether the benefits outweigh the extra dependency / complexity and I can see why you wouldn't want that, especially not for a single use-case, even though I disagree.

@chr-hertel
Copy link
Member

Yea, it's just that the problem we have to solve here and the solution don't match well - it's not overly complex in general but for converting that classes into an array, yup.

and one thing that is bad design from my point of view is to introduce a extension point to the main classes that is only needed in one specific situation. i'm def up for more extension points in this library, but i'd rather go lazy and introduce them when necessary.

i guess my perspective here is quite the opposite because i see converting MessageBag with Message classes into a Gemini compatible array structure as one single use case and that's why i don't need the overhead of decoupling on that level.

also why i would say testing is easier:

$messageBag = new MessageBag(...); // scenario x
$expected = [...]; // array structure x

self::assertSame($expected, (new GeminiPromptConverter())->convert($messageBag));

yes, it'S coupling everything into one call, but there is no more fine grained use case. let's keep it simple - at least for now 🙏

@chr-hertel chr-hertel mentioned this pull request Feb 5, 2025
39 tasks
@onemoreangle
Copy link
Contributor Author

i'm def up for more extension points in this library, but i'd rather go lazy and introduce them when necessary.

In my view they already were but I respect your decision.

Since this was a detour for me and I'm in time constraints to finish a project I can't dedicate additional time to rework it, unfortunately. Would you prefer I close this PR? Feel free to take anything you need to integrate it in a way that better aligns with the project's design philosophy.

@chr-hertel
Copy link
Member

Understood, fair enough - and anyhow, thanks for your contribution here! I will take over and make sure Gemini support lands in the lib 🙏

@chr-hertel chr-hertel closed this Feb 19, 2025
@onemoreangle
Copy link
Contributor Author

Alright best of luck and thank you for creating this lib!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants