Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Embedding Operations Very Slow for 2MB CSV File #54

Open
dkindlund opened this issue Jul 3, 2024 · 5 comments
Open

Embedding Operations Very Slow for 2MB CSV File #54

dkindlund opened this issue Jul 3, 2024 · 5 comments

Comments

@dkindlund
Copy link

Hi @danny-avila , after configuring rag_api in a docker container, it seems as though when every file is submitted from LibreChat, rag_api processes the file into chunks and sequentially handles each chunk through the embedding API one-at-a-time. For a 2MB CSV file, that process is very, very slow.

I'm wondering if you've considered processing each chunk in batches, instead? Like, could we specify a rate limit of something like: process 10 chunks at a time?

Let me know your thoughts here.

As it stands, only small files can be handled by rag_api before the LibreChat file upload times out, because of these delays.

@dkindlund
Copy link
Author

Oh, as a temp measure, @danny-avila -- maybe introduce a max file size limit field. That way, the rag_api can proactively reject files larger than X amount in size via LibreChat? (This is a precaution while larger file sizes are eventually supported.)

@nbhadauria
Copy link

I am also facing the same issue with excel file

@danny-avila
Copy link
Owner

danny-avila commented Jul 31, 2024

Thanks after doing some tests, it's nothing with the actual performance of the server/parsing process (though obviously will be slower with more chunks to process), but the real bottleneck is generating the embeddings, at least I see this on my end. This is an API call for each chunk, and this scales with "quantity" of text. Perhaps I can set a limit for max chunk size?

One approach is to make embeddings more asynchronous, though it may be tricky navigating rate limits by making them all async but it's a better appraoch. At least with OpenAI, this can be somewhat circumvented with Batch API but not all providers have this feature. Some additional settings for max async chunks would be better, in general, the async approach would definitely be faster than current, thanks for the feedback.

Usually this general RAG method doesn't serve structured data that well, either, which is why CSV to SQL is a popular strategy

@ggomp2885
Copy link

You can navigate the rate limits by putting a small time.sleep(.05) between each asynchronous API call,
It will likely be different for each api provider, so you can create an environment variable which holds a default (.2) seconds which should be more than enough, and if the user wants to speed this up they can easily reduce this value in the .env file,

I have seen this turn 1000 api calls to an LLM sequentially take 8.5hours, and when the calls are made async, it will complete all 1000 api calls in 10 minutes or less

@ggomp2885
Copy link

Solved - danny-avila/LibreChat#4081

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants