ADeus
ADeus copied to clipboard
adamcohenhillel
rag refactor
This is not ready to merge but I wanted to share my thoughts around how we store the documents.
Collecting 5 transcripts requires a new function. Given the server less environment I had to separate out the logic of processing the transcripts(since I wanted more to create more context). Right now the only solution to triggering the process-transcript endpoint would be to schedule a cron job.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| ad-deus | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Feb 27, 2024 3:29pm |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
Overall this seems like a good approach. The major question I would ask is whether we want to consolidate data as much as possible, relying on embeddings alone as a search space and optimizing the rag or whether it makes more sense to maintain structured data downstream. If the rag will work well enough that seems like a lower compute/api cost approach.
Why splitting the supabase functions to two? seems like you're not using the outpout of the first to use in the second, so not sure why the split was needed/
If there is no reason rather than "cleanness" then I think we should have one function that in charge of the audio processing, as it makes the code less "platform dependent" (for example, now you need to make changes to all hardware devices)
