We've just released R2R V3 with a completely RESTful API that covers everything you need for production RAG applications. The biggest change is our Git-like knowledge graph architecture, but we've also unified all the core objects you need to build real applications.
3. Upload your first file (or folder) of content using this command.
It's fine to have to pip install the client, but it might be worth also providing an example curl command for uploading an HTML/text/PDF file.
The quickstart confused me because it started with python -m r2r.quickstart.example or something. It wasn't clear why I need to run some quickstart example, or how I would specify the location of my doc(s) or what command to run to index docs for real. Sure I could go read the source, but then it's not really a quick start.
Also it would be good to know:
- how to control chunk size when uploading a new document
- what type(s) of search are supported. You mention something about hybrid search, but the quickstart example doesn't explain how to choose the type of search (I guess it defaults to vector search).
<< 1. Download this docker compose file.
<< 2. Run docker compose using this command.
<< 3. Upload your first file (or folder) of content using this command.
I think I will throw in the towel for now ( tomorrow is just a regular workday and I need some sleep:D ). I went the docker route with local ollama. Everything seems up, but I get an almost empty page.
To your point, I did not see the stuff GP asked for ( this is the file, this is how you run it and so on ). If I missed that, please let me know. I might be going blind at this point.
The key advantages can be extracted from the response above to Kluless -
R2R is built around RESTful API and is dockerized, so devs can get started on app development immediately.
The system was designed so that devs can typically scale data ingestion up to provider bottlenecks w/out extra work.
We have implemented user-level permissions and high level document management alongside the vector db, which most devs need to build in a production setting, along with the API and data ingestion scaling.
Lastly, we also log every search and RAG completion that flows through the system. This is really important to find weaknesses and tune the system over time. Most devs end up needing an observability solution for their RAG.
All of these connect to an open source developer dashboard that allows you to see uploaded files, test different configs, etc.
These basic features mean that devs can spend more time on iterating / customizing their application specific features like custom data ingestion, hybrid search and advanced RAG.
great question, I can talk about how we do the more challenging "List all YC founders that worked at Google and now have an AI startup."
For this we have a target dataset (the YC co directory) that we have around 100 questions over. We have found that when feeding an entire company listing in along with a single question we can get an accurate single answer (needle in haystack problem).
So to build our evaluation dataset we feed each question with each sample into the cheapest LLM we can find that reliably handles the job. We then aggregate the results.
This is not perfect but it allows us to have a way to benchmark our knowledge graph construction and querying strategy so that we can tune the system ourselves.
OK, so you have a way to evaluate the accuracy and convince yourself that it’s probably works as expected. But what about me, a user? How can I check that the question I asked was answered correctly?
We've just released R2R V3 with a completely RESTful API that covers everything you need for production RAG applications. The biggest change is our Git-like knowledge graph architecture, but we've also unified all the core objects you need to build real applications.
Check our [API](https://r2r-docs.sciphi.ai/api-and-sdks/introduction) or join our [Discord](https://discord.gg/p6KqD2kjtB) if you want to dive deeper. We'd love feedback from folks building in production!