Under the hood, we store the embeddings in a meta.embeddings table then pass back to AI the resulting IDs for each embedding. We do this because embedding vectors are big, and sending these back and forth to the model is not only expensive, but also error prone. Instead, the language model is aware of the meta.embeddings table and simply subqueries to it when it needs access to an embedding.
A couple Qs if anyone knows:
1. What does it mean to "pass back to AI the resulting IDs for each embedding" but not the table rows corresponding to the matched vectors?
2. Does "the language model is aware of the meta.embedding table" mean Supabase has deployed a fine-tuned GPT-4o?
1. You can see the relevant code block here[0]. To summarise, instead of storing the embeddings "next to" the data that you provide, we create a table that can be referenced. This is because often we need to send the LLM some data from the table (like creating a chart). If the LLM sees a reference to `meta.embeddings` then it knows it can "fetch" that data later if it's needed (for RAG etc)
2. We haven't fine-tuned, it's all just detailed prompts which you can find in the code. We might need to fine tune later for local-only models, but for now GPT-4o is solid.
1. What does it mean to "pass back to AI the resulting IDs for each embedding" but not the table rows corresponding to the matched vectors?
2. Does "the language model is aware of the meta.embedding table" mean Supabase has deployed a fine-tuned GPT-4o?