How RestGPT differs from ToolLLM or Gorilla?<p>papers:<p>1. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs <a href="https://arxiv.org/abs/2307.16789" rel="nofollow noreferrer">https://arxiv.org/abs/2307.16789</a><p>2. Gorilla: Large Language Model Connected with Massive APIs <a href="https://arxiv.org/abs/2305.15334" rel="nofollow noreferrer">https://arxiv.org/abs/2305.15334</a>
The problem here is where these actions come from. Generic LLM cannot generate correct actions in many (if not most) real life cases. So, it will have to learn, and LLMs aren't good at learning. For example: "I'm tired, play my favorite". The action depends on _who_ is saying and on what's going on right now. There may be someone sleeping, or watching TV. I'm afraid that acceptable solution is much more complicated.
"Gorilla: Large Language Model Connected with Massive APIs" (2023) <a href="https://gorilla.cs.berkeley.edu/" rel="nofollow noreferrer">https://gorilla.cs.berkeley.edu/</a> :<p>> <i>Gorilla enables LLMs to use tools by invoking APIs. Given a natural language query, Gorilla comes up with the semantically- and syntactically- correct API to invoke. With Gorilla, we are the first to demonstrate how to use LLMs to invoke 1,600+ (and growing) API calls accurately while reducing hallucination. We also release APIBench, the largest collection of APIs, curated and easy to be trained on! Join us, as we try to expand the largest API store and teach LLMs how to write them!</i><p>eval/:
<a href="https://github.com/ShishirPatil/gorilla/tree/main/eval">https://github.com/ShishirPatil/gorilla/tree/main/eval</a><p>- "Gorilla: Large Language Model connected with massive APIs" (2023-05) <a href="https://news.ycombinator.com/item?id=36073241">https://news.ycombinator.com/item?id=36073241</a><p>- "Gorilla: Large Language Model Connected with APIs" (2023-06) <a href="https://news.ycombinator.com/item?id=36333290">https://news.ycombinator.com/item?id=36333290</a><p>- "Gorilla-CLI: LLMs for CLI including K8s/AWS/GCP/Azure/sed and 1500 APIs (github.com/gorilla-llm)" (2023-06) <a href="https://news.ycombinator.com/item?id=36524078">https://news.ycombinator.com/item?id=36524078</a>
It seems after 1-2 years that the true power of LLMs is in DevOps. I got pretty excited when I tried GPT-3 (completion model), but as time went by and OpenAI shifted to chat models, we lost control over the LLM part and found new meaning in taking whatever model OpenAI made available as a blackbox and "chained" it to other tools we already had, like data bases, APIs, function calls/tools, etc. I'd say DevOps is exactly where open source is seriously behind; there are decent open source models but it costs so much to self host them, despite the full power and control we have on them (via text generation webui and the like).<p>OpenAI is playing the DevOps game (starting maybe with introduction of ChatML). Open source community plays the LLM and benchmarks game. Ironically, the two are converging, meaning that OpenAI's models are getting dumber (not the API) thanks to censorship and RLHF, to the point that open source models are even better than some OpenAI models in some aspects. On the other hand, open source models are getting better tooling and DevOps thanks to oobabooga, llama.cpp, etc.<p>I'm seriously waiting for competitors to change nVidia's monopoly in this space. Maybe Apple?
ChatGPT + Noteable is already powerful to get some work done via API calls (after installing and importing the libraries, writing Python code, managing secrets for authentication etc)<p>There is surely scope to streamline this much further<p>I am very intently watching this space
Separating the language model from the knowledge model (and then splitting that into domain specific knowledge models) is the next low(ish) hanging progression step in the field.
This is interesting, I do something similar with unfetch.com - I have some examples on unfetch.com/directory - There are a lot of potential use cases for LLm & APIs