You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
where CallData and ModelConfig are other data types as well: everything becomes much more self-documented. Furthermore, you don't have to build maps (i.e. dict) on the fly inside the methods.
You could also define a common interface, e.g. BaseLLMResult and have OpenAIResult extend it.
The text was updated successfully, but these errors were encountered:
I am trying to avoid defining these until I start adding LLMs from other providers. Any idea on how we can make this generic enough beforehand?
Yes: you can define abtract data types and extend them whenever you get into a different provider e.g., OpenAIResult could just extend BaseLLMResult - if we assume that you will get a result most times. 😀
The beauty of having abstract interfaces is that you do not have to think about all the possible providers at once.
Reevaluating this since I added support for another LLM and the need for this becomes more obvious. My worry is that dataclasses are not serializable by default
llmflows/llmflows/llms/openai.py
Line 80 in 6ce79a8
I would always consider whether to make my code more informative and cleaner by e.g. making a specific data type out of a tuple.
Consider e.g.
where
CallData
andModelConfig
are other data types as well: everything becomes much more self-documented. Furthermore, you don't have to build maps (i.e.dict
) on the fly inside the methods.You could also define a common interface, e.g.
BaseLLMResult
and haveOpenAIResult
extend it.The text was updated successfully, but these errors were encountered: