Recent submissions

Comment · 11 months ago
Have you checked out https://docs.onyx.app/deployment/getting_started/quickstart#...?

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.

Comment · 11 months ago
Yep, we have our own implementations! We've spent a lot of time on them, and in our internal benchmarks they compare pretty favorable to the native versions.

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!

Comment · 11 months ago
A few reasons:

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.

Comment · 11 months ago
Reposting from https://news.ycombinator.com/item?id=46047430:

---

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).

Comment · 11 months ago
You could! We have a number of users who do something like that (e.g. Ramp's in-app chat bot is powered by Onyx)
Comment · 11 months ago
Great suggestion! I haven't heard of it before, but I'll definitely add it to the list.

Would love to hear your feedback after you get a chance to try Onyx out.

Comment · 11 months ago
Thanks! Especially these days, refinement is (by far) the hardest part :)
Comment · 11 months ago
> One thing I really care about is extensibility

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?

Comment · 11 months ago
We have! Likely not for a while, since we want to focus on the web app for a bit more. But long term that would be the plan.

Things like shortcuts to access the chat + ability to reach into the local file system are very compelling.

Comment · 11 months ago
Yes indeed! Our belief is that tool design, compaction (e.g. tool result summarization), and reminders are the things that separate a product that works magically vs one that falls over on any slightly more complex task.

And this is all made all the more important when supporting the wide range of models, even "weaker" open-source models.

Comment · 11 months ago
Comment · 11 months ago
What format are the docs being uploaded as? By default, images uploaded into the chat would be directly passed through. PDFs would be parsed and fed to the LLM as text.

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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton