Embedding Operations Very Slow for 2MB CSV File
dkindlund opened this issue · 5 comments
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.
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.)
I am also facing the same issue with excel file
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