Supporting asyncio in langchain primitives allows for users to run them
concurrently and creates more seamless integration with
asyncio-supported frameworks (FastAPI, etc.)
Summary of changes:
**LLM**
* Add `agenerate` and `_agenerate`
* Implement in OpenAI by leveraging `client.Completions.acreate`
**Chain**
* Add `arun`, `acall`, `_acall`
* Implement them in `LLMChain` and `LLMMathChain` for now
**Agent**
* Refactor and leverage async chain and llm methods
* Add ability for `Tools` to contain async coroutine
* Implement async SerpaPI `arun`
Create demo notebook.
Open questions:
* Should all the async stuff go in separate classes? I've seen both
patterns (keeping the same class and having async and sync methods vs.
having class separation)
text-davinci-003 supports a context size of 4097 tokens so return 4097
instead of 4000 in modelname_to_contextsize() for text-davinci-003
Co-authored-by: Bill Kish <bill@cogniac.co>
Add
[`logit_bias`](https://beta.openai.com/docs/api-reference/completions/create#completions/create-logit_bias)
params to OpenAI
See [here](https://beta.openai.com/tokenizer) for the tokenizer.
NB: I see that others (like Cohere) have the same parameter, but since I
don't have an access to it, I don't want to make a mistake.
---
Just to make sure the default "{}" works for openai:
```
from langchain.llms import OpenAI
OPENAI_API_KEY="XXX"
llm = OpenAI(openai_api_key=OPENAI_API_KEY)
llm.generate('Write "test":')
llm = OpenAI(openai_api_key=OPENAI_API_KEY, logit_bias={'9288': -100, '1332': -100, '14402': -100, '6208': -100})
llm.generate('Write "test":')
```
Add `finish_reason` to `Generation` as well as extend
`BaseOpenAI._generate` to include it in the output. This can be useful
for usage in downstream tasks when we need to filter for only
generations that finished because of `"stop"` for example. Maybe we
should add this to `LLMChain` as well?
For more details, see
https://beta.openai.com/docs/guides/completion/best-practices
Signed-off-by: Diwank Singh Tomer <diwank.singh@gmail.com>
this is the second PR of #519.
in #519 I suggested deleting Extra.forbid.
I was very confused but I replaced Extra.forbid to Extra.ignore, which
is the default of pydantic.
Since the
[BaseLLM](4b7b8229de/langchain/llms/base.py (L20))
from which it is inherited is set in Extra.forbid, I wanted to avoid
having the Extra.forbid settings inherited by simply deleting it.
As talking #519, I made 2 PRs.
this is the first PR for adding a logger.
I am concerned about the following two points and would appreciate your
opinion.
1. Since the logger is not formatted, the statement itself is output
like a print statement, and I thought it was difficult to understand
that it was a warning, so I put WARNING! at the beginning of the warning
statement. After the logger formatting is done properly, the word
WARNING can be repeated.
2. Statement `Please confirm that {field_name} is what you intended.`
can be replaced like `If {field_name} is intended parameters, enter it
to model_kwargs`
thank you!
Yongtae
Hi! This PR adds support for the Azure OpenAI service to LangChain.
I've tried to follow the contributing guidelines.
Co-authored-by: Keiji Kanazawa <{ID}+{username}@users.noreply.github.com>
Addresses the issue in #76 by either using the relevant environment
variable if set or using a string passed in the constructor.
Prefers the constructor string over the environment variable, which
seemed like the natural choice to me.