-
Notifications
You must be signed in to change notification settings - Fork 3
Why Archytas over LangChain
langchain defaults to GPT-3 (Davinci), but GPT-3 has limited planning capacity and frequently fails to accomplish mildly complex tasks. GPT-4 is much more capable, and quite necessary to have a chance at doing most of the things that are useful but complex
langchain supports the GPT-3.5/GPT-4 chat-style API interface, but the prompting is not good enough. Frequently both to get the llm output to conform to the langchain interface
Tools created in langchain must be a function that take a single string as input, and then return a single string as output. If the tool wants to use a different type or have multiple inputs, it must explicitly handle parsing the input string into the desired shape. And same for any output which must be manually converted to a string format so the LLM can understand it. Additionally, it is up to the tool developer to explain to the LLM any expectations for the input so that it can be parsed accordingly. This is pretty ad-hoc if you're doing anything more complex than string in, string out.
Archytas has a consistent interface for all tools it presents to the LLM: JSON values. Tools can take any number of arguments, that may be any valid python-equivalent of JSON objects
dictlist-
int/float boolstrNone
When the LLM is interacting with tools, Archytas will automatically parse/convert the LLM string into the specified signature for calling the tool. Then when the tool returns it's response (if any), archytas will convert it back into a string the LLM can understand. This means that your tool functions can look much more like regular functions with multiple arguments, typing, etc. and aren't forced to conform to the def mytool(s:str) -> str interface required by langchain
If your python-fu is strong then yes you can certainly create a langchain tool that has state (e.g. by making a class instance, and then pulling one of the bound methods out to be the tool). However Archytas can handle Class tools/toolsets, i.e. tools that maintain some sort of internal state.
archytas tools can raise exceptions, which then get caught and shown to the LLM in a consistent manner. In the Archytas ReAct loop, the LLM can then seamlessly recover from errors encountered while using tools, based on the exceptions. (TODO: lookup how langchain handles exceptions during tool usage)
(in langchain, when making a tool, you had to explain in detail how your tool worked so the llm could use it. but it wasn't really obvious how to explain the precise format that inputs/outputs should take.)(archytas has a very clear paradigm that is responses are parsed as json, tool input arguments are extracted from fields in the json. prompt for this is generated automatically assuming the tool is type annotated and has a matching docstring)