yuhongsun

Sounds like Danswer might just fit your needs. Also ya, we came up with this idea of chatting with documents that you can select on the fly, I think we're the only ones who do this still. People have really been liking that one!

If you happen to want to talk to us about Danswer, we'd love to welcome you to our Slack: https://join.slack.com/t/danswer/shared_invite/zt-2afut44lv-...

We definitely recommend you trying it out!

As far as how outdated information is handled - we pass the most relevant documents along with metadata to the LLM. So in the case you mentioned, the LLM will be provided the procedure doc and the time it was updated, the relevant Slack messages and the times they were sent, and the call transcripts along with when the call happened. The LLM tends to handle this pretty well.

Additionally, during the retrieval phase, there's a time based decay applied based on the last time the document was updated. Also there is learning from feedback so users can upvote documents that are useful and downvote documents that are deprecated.

Got it, we considered it but most connectors that we pull from don't support this. Might bring it back for the ones that do, thanks for the suggestion!

It's actually still in the code, just none of the connectors implement it atm: https://github.com/danswer-ai/danswer/blob/main/backend/dans...

Do you mean directly uploading files in the UI and chatting against those files? This one will be done within the next few weeks, it's a very high value item for sure.

Alternatively, if you're talking about real time indexing to make it available to everyone immediately, there's an Ingestion API, where users can send documents in the expected format directly to the system, is this what you're thinking?

The integrations are built in house, some using client libraries of the particular tool (like the Atlassian python client library for example). We considered using Airbyte, LlamaHub etc. but we found that they don't support the full flexibility that we need, including pulling incremental updates and access permissions.

Ya, there's definitely a common thread there! A lot of consulting firms have given us very positive feedback from using Danswer. I think the nature of the time-framed projects and frequent scope changes mean that people have to always take in new information and a lot of documented knowledge is lost or at least difficult to find.

A great use case for sure!

A lot of teams we talk to switched from an in-house solution to either directly using Danswer or building on top of Danswer. Glad you liked the demo!

We're using E5 base by default but there's an embedding model admin page to choose alternatives. There's also an API for it if you know what you're doing, you can even set one of the billion+ parameter LLM bi-encoders if you want (but you'd need a GPU for sure).

I definitely see what you mean. They also have advantages in bundling co-pilot with their other offerings. This will in no means be an easy battle for us, but we have hope that we'll be able to build something people love and end up using!

Thanks so much! It's always rewarding to hear people sharing our excitement!

We're leaning heavily into the open source aspect. We think that a solution like this will be useful to even smaller teams (10-50) that other companies won't want to target. There is some non-trivial amount of setup required, specifically chasing down the API keys etc. So for the SaaS alternatives, they rely heavily on their sales orgs being very hands on so it makes no sense for them to target small teams. In fact for many of them, if you try to sign up for a demo and you say you're less than 50 people, they straight up ignore you.

So hopefully teams will self-adopt Danswer and as they grow, they will keep using us!

For larger teams, the transparency and peace of mind of self-hosting an open source solution is also a major benefit. We've often heard from large teams that have adopted Danswer, that the customizability of it has been a driving factor in their adoption. They want to own the solution and they want to customize it specifically for their needs. At the very basic level, a lot of teams have swapped in domain specific embedding models and prompts but we've seem some significantly more involved customizations as well.

Yes! And we'd love it if you contribute them back to the project! More than half of the connectors are community contributed at this point and it's by far the most common area of contribution.

There's a simple Document interface that needs to be implemented to provide stuff like title, content, link, etc. From there the rest of the Danswer code takes it and handles the indexing and making it available for querying.

There's a contributing guide here: https://github.com/danswer-ai/danswer/blob/main/CONTRIBUTING...

And a connector contributing guide here: https://github.com/danswer-ai/danswer/blob/main/backend/dans...

This is also another reason why we think OSS is the way to go here. Taking on the tech giants alone is definitely a daunting task (maybe even impossible for a small isolated team).

The hope is that by working with the community, we'll be able to incorporate the best ideas and contributions from a large pool of like-minded people to build something everyone can benefit from!

The OSS space has absolutely taken off in the NLP space and the excitement has bled over to developer platforms resulting in some outstanding projects, hopefully the same will happen with LLM applications.

So the intent of the GitHub/GitLab connector in the current iteration is to help people easily find implementations that have been done before. For example, if a new bug comes up with some feature, I can easily search for the PRs relating to that feature in natural language and filter down the code changes that may have caused it.

Glad you asked! We are actually the only project (open source or closed), as far as I know, that handles multilingual quite well. We have options to do multilingual query-expansion and also multilingual embedding models.

Without dropping any names, a big french company with 5000 people is actually doing this with Danswer and have found great success.

There is some info here: https://docs.danswer.dev/configuration_guide You'll also want to change the embedding model in the admin UI

Code search is something we have in our sights in the next couple months. Currently the GitHub connector pulls in PRs and Issues but not the whole code base. We wanted to have the best RAG pipeline so we deep dived on that. Code search uses a combination of graph based traversals and a different type of embedding so it's a separate effort, but we will definitely build it out since it's immensely useful to engineering teams!

A lot of people are very bullish on AI, it's very interesting to hear the opposite side. My opinion is that LLMs are very powerful at digesting and distilling knowledge which is why we built this project. I also think that LLMs are terrible reasoning engines and so agent-flows are not quite ready for primetime.

Would love to hear your perspective on the space!

I think these developer platforms like LlamaIndex and Langchain are super great for prototyping and understanding the crowdsourced best approaches in solving these new LLM related challenges.

Depending on how custom the pipelines need to be, you'll either find that you've saved a huge amount of time using these libraries, or you'll find that you have no option but to switch off and build from scratch.

Thank you!

Yes, there are several options for user authentication (Basic Auth, Google OAuth, OIDC, SAML).

Currently the RBAC is managed via the Danswer and this controls who has access to which documents (it's done at the connector level as it would be untenable to assign access to documents individually).

We're also working on automatically sync-ing permissions from the sources. Basically seeing which emails have access to each doc and mapping it to the Danswer users.

Yes! There is Basic Auth (email + password with email verification) and Google OAuth available in the free version.

We also do OIDC and SAML to integration with Identity Providers (IdPs) like Okta but that's part of the paid features. Ahhh please don't hate us!

Thanks! Yes, it does do PDFs. We don't do anything fancy with it though like Optical Character Recognition (OCR). So pictures of text, as well as images and graphs will be lost. This is something we will work on though.

Is this something that you would find a lot of value in or is simple text processing of PDFs sufficient?

We use LlamaIndex very sparingly. Specifically the context aware document chunking functionality is via LlamaIndex.

We couldn't use the more involved pipelines because we needed significant custom logic to enforce permissions, filters (like time filter, source filter, document-set filters), and other complexities. At that point, it's easier to write from scratch rather than conform to expectations of these third party libraries.

Ya, parsing the file is generally not bad at all. The problem comes with the fact that LLMs are notoriously bad with numbers and formatted data. So the current approach of passing relevant information to the LLM and asking it to generate answers will produce misleading information when larger tables are passed in.

By asking the LLM to generate a formula though, it doesn't actually need to do any number crunching of its own which makes solving the challenge a bit more reliable when it comes to LLMs.

Ya, handling spreadsheets is a beast of its own. We have this simple implementation to cover easy cases for folks but likely it will need its own more involved pipeline for indexing, retrieval, and interactions with the LLM.

Currently with large tables, it's not handled very well either. The more complete approach would be to pass the headers to the LLM and ask it to generate a formula to parse the data rather than feeding the whole table(s) to the LLM directly.

Some of the bigger items we want to target that require special flows are code search, SQL tables, and Excel/CSVs/TSVs

Ah yes, this reminds me! I forgot to mention it but for the local NLP models that we run, they're in the range of 100 million parameters so they're able to be run on CPU (no GPU required!) with pretty low latency.

Also a fun tidbit on the connectors, more than half of them now are built by open source contributors! We just have an interface that needs to be implemented and people have been able to figure it out generally.

I think I understand your concern but if I miss the point, please follow up!

So regarding getting access to read knowledge from the different tools, it depends tool by tool but a lot of them have API keys or options for app integrations available in the free tier (GitHub, Google Drive, Confluence come to mind). Other tools don't have a free tier and you just get access to the API keys as a part of paying for the service. I think there are probably tools that require a premium fee to get integration access but I'm not aware of any personally.

For the SlackBot, it can add itself to public channels but for private channels someone needs to add it. It is what it is sadly.

About search being available for most SaaS products: SaaS tools are definitely improving their own searches. But I still think a single place to search and aggregate data has significant value. For example, as an engineer by training, often getting the full picture for some customer escalation includes reading Slack threads, Confluence Design docs, old Pull Requests on GitHub. Would be nice to get it all in one place.

Yes, we have an API and a way of accessing it with a generated API key which you can find in the admin panel.

Two things to note though.

The APIs are intended for serving the Danswer frontend. The functionality is generally complete for similar use cases but it's not documented so you have to look at the code.

If you're overusing the API on the cloud without providing your own OpenAI key, we will likely have to shut down the instance to prevent losing too much on inference fees.

We chose FOSS because we think this type of tool will be universal in the near future. We likely won't be able to directly serve millions of teams ourselves by the time it happens but by open sourcing, if teams want it, they can just set it up.

Especially with small teams that have no budget, they can get value and never need to talk to us. We hope to grow with them.

In terms of funding and the economics of it, we have a cloud currently which is paid and we're developing additional features that are not free. For example, identifying experts on the team when the system is unable to find the information to answer the question directly. This is an example of a feature that large teams are likely willing to pay for but small teams won't need (as they know each other intimately).

Thank you for the kind words!

Email: founders@danswer.ai Slack: https://join.slack.com/t/danswer/shared_invite/zt-2afut44lv-... Discord: https://discord.gg/TDJ59cGV2X

We hear this a lot - we take it to mean we've found something that people like and need!

We have a strong emphasis on the retrieval half of RAG. A big part of the value of Danswer is in connecting to sources like Notion, Linear, GitLabs, etc. We do incremental updates to keep data fresh, pull in metadata, etc. We also have features to manage access to documents in Danswer like RBAC.

Basically, (as I understand it) OpenWebUI is more like a ChatGPT frontend and we're more like a unified search with an emphasis on LLMs.

Thanks!