henomis
Add SetFunctions to OpenAI LLM
Description
I have a specific case where I'm modifying the functions' description, mostly enum options, at run time. The issue is that the current struct-based approach makes it too difficult.
The solution is having a SetFunctions method for the LLM, so we can create our own function's schema. This two lines of code will save a lot of pain:
// File: llm/openai/function.go
// SetFunctions is a setter the functions list
func (o *OpenAI) SetFunctions(funcs map[string]Function) { o.functions = funcs }
Fixes #228
Type of change
Please delete options that are not relevant.
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
- [x] Regular unit tests
Checklist:
- [x] I have read the Contributing documentation.
- [x] I have read the Code of conduct documentation.
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my feature works
- [x] New and existing unit tests pass locally with my changes
- [x] I have checked my code and corrected any misspellings
Policy on Unattended Pull Requests
As part of our commitment to maintaining an active and collaborative development environment, it's important for pull requests (PRs) to receive timely attention and feedback. PRs left unattended for an extended period can impede progress and create bottlenecks in the development process.
Therefore, if a PR remains unapproved and unmodified following a review for an extended period, the author of the PR reserves the right to implement the suggested modifications at their discretion.
The specific duration of time before this policy is enacted may vary depending on the circumstances and urgency of the changes. However, as a general guideline, a reasonable timeframe for review and action might be 2 weeks.
This policy aims to ensure the continued progress of the project while respecting the contributions and efforts of all team members. It encourages timely collaboration and feedback while preventing PRs from stagnating indefinitely.
If you anticipate being unable to review or address a PR within the specified timeframe, please communicate this with the team to avoid invoking this policy unnecessarily.
