Totally agree with the project goals, it seems too many other packages are created by people who are researchers (or enthusiasts) first and software developers second, and it shows.
I see you're using Pydantic. I've recently been playing with using pydantic to implement chatgpt functions, making it a bit easier to define functions (tools) with more control over the attributes, like this:
class SearchWeb(pydantic.BaseModel):
"""
Docstring description to help GPT figure out what this does, like functions in your library.
"""
query: str = pydantic.Field(description="More info so GPT understands how to use this param")
def handle(self):
# my wrapper will call this to implement the tool after the arguments are parsed
# at this point you can be sure self.query is correct and has passed any validation you might have
It's definitely more verbose than the function definitions you have now, but you get schema definition for free, and is more strict about option parsing. It also makes it easy to throw errors back at GPT if it hallucinated some parameters incorrectly.
...aaaanyways, great work there, I'll be following the progress!
Currently integrating this approach into PythonGPT[1], which will build a function on the fly, extract the method info, then call the code in exec(). I would label it "very dangerous"...
> There was another post today about using Pydantic for function enabled completions
That post let me know that pydantic's schema() function actually worked to produce a valid JSON schema, so I was able to optimize from there. (there may be a few optimizations still to be done: schema() also returns an unnecessary title field and I need to experiment if I need to remove it)
Not a sin, I don't want to diminish in any way the awesome work that's being done!
It's just that these packages/libraries/frameworks are often in what I'd describe as "proof of concept" phase, not very developer-friendly (as in user-friendly for people wanting to try it out), missing docs, not handling errors, and not being written in a maintainable way.
So I think a "second generation" of tools/libraries, that are basically product-level quality, bringing on your work and focusing on those non-core-tech aspects of the experience, will be a next step to bring AI to the (developer) masses. Tools such as this package.
I hope you keep investing in this project- it’s a crowded field but I do think existing projects like Langchain and LLamaindex feel very bloated and beyond a refactor - sometimes we need fresh takes like this and start over.
I am: the reason I made simpleaichat is because I have a need for more controllable work with AI generation, and it was easier to create a package from scratch than to figure out how to hack LangChain.
Is interfacting with the GPT-4 API acting as if you are the ChatGPT UI against terms of service? I was under the impression it was and they had a bunch of methods to protect against this. They want you using ChatGPT for $20/mo and then paying for GPT-4 API usage separately per token from what I can tell.
On the other hand, automatic retires can be suprising, especially when they don't completely understand the returned error and retry on errors they shouldn't.
I just wasted a couple hours the other week due to langchainjs defaulting to retrying errors which were ultimately caused by timeouts and would never complete.
The underlying library for both sync and async is httpx (https://www.python-httpx.org/) which may be limited from the HTTP Client perspective but it may be possible to add rate limiting at a Session level.
My open source CLI tool can do this, as well as make changes to the code. Here's a chat transcript that shows how you can use it to explore and then modify a public github repo for a js game:
I take it that asking things about the repository with gpt3.5-turbo-16k is not possible without adding each file separately?
Just to test I generated ctags for my smallish Rust project and noticed it comes to around 10k tokens according to https://platform.openai.com/tokenizer.
I don't have GPT-4 API access yet but it appears it would get quite expensive with the 32k context.
Correct, right now aider does not provide the ctags repo map to any gpt-3.5 models. I still need to evaluate if those models can actually understand and use the map effectively.
Improving and deepening support for the 3.5 models is probably my top priority next effort. Previously, they were barely useful for editing code. The 16k context window and functions support may have shifted that balance, so I need to dig in more.
One other thing to note is that aider now distills the repo map to fit within a token budget. The default is 1k tokens, specified via `--map-tokens`. It tries to use the budget to convey the most important parts of the repo map to GPT. So in theory, even very large repos should get a useful map.
I wrote a simple ChatGPT plugin that exposes files within a local directory on my computer to ChatGPT [0]. It's been quite helpful for me, both for working with codebases as well as other material (supports docx and pdf as well). It does require plugin developer access to run, though.
Totally agree with the project goals, it seems too many other packages are created by people who are researchers (or enthusiasts) first and software developers second, and it shows.
I see you're using Pydantic. I've recently been playing with using pydantic to implement chatgpt functions, making it a bit easier to define functions (tools) with more control over the attributes, like this:
It's definitely more verbose than the function definitions you have now, but you get schema definition for free, and is more strict about option parsing. It also makes it easy to throw errors back at GPT if it hallucinated some parameters incorrectly....aaaanyways, great work there, I'll be following the progress!