nextjs-openai-doc-search VS fts-benchmark

https://supabase.com/blog/openai-embeddings-postgres-vector

https://supabase.com/blog/chatgpt-supabase-docs

There is already AI built into the docs - just hit cmd+k and ask a question. we were one of the first to do this: https://supabase.com/blog/chatgpt-supabase-docs

We were inspired by what supabase did with the creation of their own ai powered assistant here: https://supabase.com/blog/chatgpt-supabase-docs but we wanted to make one that used a more standard backend in redis and ruby.

https://release.com/blog/training-chatgpt-with-custom-librar...

We were inspired by what supabase did with the creation of their own ai powered assistant here: https://supabase.com/blog/chatgpt-supabase-docs but we wanted to make one that used a more standard backend in redis and ruby.

Gromit is super new; please give it a shot and make pull requests, leave comments, we would love to chat with you about it!

This is the same approach that Supabase Clippy took: https://supabase.com/blog/chatgpt-supabase-docs

They called it "context injection" but the OpenAI community appears to call it "retrieval-augmented generation".

(Tangent) I will go to the grave continuing to call it Supabase Clippy even though presumably this prediction from the Supabase blog post became true:

> Today, we're doing our part to support the momentum by releasing “Supabase Clippy” for our docs (and we don't expect this name to last long before the lawyers catch on).

> the trick where you search for relevant content and paste that into a prompt

Supabase Clippy was the first docs site to ship this experience to production as far as I can tell: https://supabase.com/blog/chatgpt-supabase-docs

I believe they called it "context injection" and I have been following suit in my own writing on the topic.

I am prototyping experiences like Supabase Clippy and am also very interested in fine-tuning for docs Q&A. But my main question is: what exactly would the fine-tuning inputs and outputs look like for docs Q&A?

From my blog:

> AI is all about prediction. Given this temperature, this wind, this day of the year, what is the chance of rain? Temperature, wind, and date are your inputs. Chance of rain is your desired output. Now, try to apply this same type of thinking towards documentation. What are your inputs? What’s your output? The page title and code block could be your inputs. Whether or not the code builds could be your output. Or maybe the code block should be the output? This is why I keep saying that applying fine-tuning to docs is tricky. What are the inputs and outputs?

https://technicalwriting.tools/posts/ten-principles-response...

(I am an AI n00b and have not looked deeply into how fine-tuning works but it's high on my list to experiment with OpenAI's fine-tuning API. Please LMK if I am getting any fundamentals wrong.)

Make sure to check out https://supabase.com/blog/chatgpt-supabase-docs!

Can try this: https://github.com/supabase-community/nextjs-openai-doc-search

It depends on what the user requirements are. FTS works pretty well with both Postgres and SQLite, in my experience.

Here's a git repo someone can modify to do a cross comparison on a specific dataset, if they are interested. It doesn't seem to indicate the RMDBs are outclassed in a small-scale FTS implementation.

https://github.com/VADOSWARE/fts-benchmark