Weves
Joined 3 years ago
Joined 3 years ago
RAG specifically is our speciality - we've done a ton of optimizations there (hybrid search, document age-based weighting, giving the LLM the ability to read more from interesting docs and less of irrelevant docs, etc.) and we outperform the implementation within ChatGPT quite substantially in internal blind testing.
Curious what you find if you compare them head to head though!
1/ No model lock-in / ability to use the ideal model for each use case.
2/ More connectivity. A fuller connector library (contributed to by the open-source community). More built-in tools (similar to the ^).
3/ Customizability and flexibility. If you really need a feature, you can build it rather than waiting months (years?) for your request to go through.
4/ White-labeling. You can make it feel like a product built for/by your company rather than generic.
---
Broadly, I think other open source solutions are lacking in (1) integration of external knowledge into the chat (2) simple UX (3) complex "agent" flows. Both internal RAG and web search are hard to do well, and since we've started as an enterprise search project we've spent a lot of time making it good.
Most (all?) of these projects have UXs that are quite complicated (e.g. exposing front-and-center every model param like Top P without any explanation, no clear distinction between admin/regular user features, etc.). For broader deployments this can overwhelm people who are new to AI tools.
Finally trying to do anything beyond a simple back and forth with a single tool calls isn't great with a lot of these projects. So something like "find me all the open source chat options, understand their strengths/weaknesses, and compile that into a spreadsheet" will work well with Onyx, but not so well with other options (again partially due to our enterprise search roots).
Would love to hear your feedback after you get a chance to try Onyx out.
Totally makes sense! We've defined simple `Connector`, `Tool` and (soon) `Agent` interfaces to make it easy to plug in your own implementations/apps. If you wanted, you could just use Langchain under our Agent class to build arbitrary flows.
Additionally, the main chat is created from a series of `Renderer` components, and it should be easy to build your own.
Do you think that's in-line with what you're thinking of, or do you want to build outside of those confines?
> canvas mode and scheduled actions
Yes, writing and recurring are two big areas we want to tackle next year.
> The main thing I really care about is voice mode
Interesting. Why do you think that is?
Things like shortcuts to access the chat + ability to reach into the local file system are very compelling.
And this is all made all the more important when supporting the wide range of models, even "weaker" open-source models.
we have all of those!
> how onyx is comparable
For an AI-powered research assistant, Onyx might just work out of the box. We have ~45 connectors to common apps (https://github.com/onyx-dot-app/onyx/blob/main/backend/onyx/...), integrations with the most popular web search providers (https://github.com/onyx-dot-app/onyx/blob/main/backend/onyx/...), and a built in tool calling loop w/ deep research support (https://github.com/onyx-dot-app/onyx/blob/main/backend/onyx/...). If you wanted to customize, you could pretty easily tweak this / add additional tools (or even rip this out completely and build your own agent loop).
Writing is a really common use case, and something we'd like to explore more. Currently people often use Onyx for "write something combining X, Y, and Z documents", but I feel that's just scratching the surface.
We should definitely update the Local guide to reflect the ^, thanks for pointing that out.
For the container footprint - pretty much all of them are necessary to run locally. We hope that just a large # of containers shouldn't be a problem, as long as they are all lightweight (e.g. total resource utilization is low). We of course could bundle them together into a single "mega container", but that seems against the best practices of Docker.
On a related note, we are looking to have a version that doesn't require the vector database (the heaviest part of the system in terms of resource utilization). Our goal is to have a deployment mode with less than 1gb of RAM required.