(But then, my current design isn't too different from the one I've been using for over a decade, and it's gone from fashionable to retro in that time).

> I made my current website layout by asking ChatGPT.

Not a frontend developer, but curious what prompt(s) you used?

I can't remember exactly, but it would've been a plain English description of what I wanted it to look like, and asking it for CSS to do that.

This is the future of self support. Instead of those shitty chat bot state machines that only offer the same FAQ you just searched through, it now can infer all your company documentation to your users (external facing of course) so that they can find exactly what they are looking for. MDN docs would be easily searchable (I mean, they already are really accessible). Your company’s fizzbuzz wizbang-SNAPSHOT-bim.bam.boom.jar docs would actually make sense to humans and your engineers will no longer have to be in customer meetings!

Wonder how often it hallucinates features you don’t have

Probably also not any more frequent than your average sales guy (at least those that overpromise _every_ feature to their leads/accounts and casually ask you to whip it up and ofc deploy it on a friday afternoon so the promise they made to the strategically and overall super important client isn’t revealed as utter lies).

A solution like this might be fantastic for docs testing. If docs are indeed the single source of truth for technical products (alongside code), a GPT powered assistant can help identify gaps.

Needs to do a bit more. It choked on a 400 page doc site I tried (at least with the free tier I have access too).

I would really like to see it in action on a docbase I'm familiar with, though.

Edit: Just tried again, and it hangs on doc 55 out of 421.

Here's the site if anyone else wants to give it a go: https://github.com/fusionauth/fusionauth-site/

Yes, we plan to do this in background workers soon so that it can carry the load.

If I have fairly fixed documentation and documents (won't be updated in months), what's the benefit of using a vector database (e.g. pinecone or supabase w/ vectors) rather than just saving the pickle (pkl) file and looking it up every time?

Shouldn't using the pickle file be much faster/more efficient?

If you have a small number of fixed documents e.g. <100k or so, then I agree that pickling the vectors or storing them as bytearrays would work better.

Once you reach a certain scale, it's helpful to potentially use distributed querying and/or different index types, even if you have a fairly static dataset. You can check out a billion-scale search benchmark we recently did here: https://zilliz.com/resources/milvus-performance-benchmark (you'll need to supply your email unfortunately). Here's the framework we used as well: https://github.com/zilliztech/vectordb-benchmark

This looks very nice — a great improvement over existing search engines for docs. It’d be great if it could also scan restructuredText and Asciidoc docs repos.

Yes, this will come, we had to start somewhere. Would love a PR on this, should be straightforward.

I filed an issue a few hours ago. https://github.com/motifland/markprompt/issues/5 (for asciidoc)

Thanks!

these gpt wrapper apps as a business model are going the way of the dodo, things are moving way too fast

In what way? This seems very useful.

Plugins are coming, and wrappers are still having to pay openAI and on top of that their own slice of the pie. Since wrappers aren't really cultivating the information themselves, nothing is stopping you from making your own either, the openAI API isn't a big difficult secret. You can even ask openAI to write your own integration for you!

You can probably also ask openAI about the nextjs/tailwind starter repo everyone of these wrappers keep relying on too.

100% agree on the wrappers. Though, keep in mind that even if you can write your own it does not mean you can support it or even keep up with the latest trends / features. Hacking something over the weekend is doable but supporting long term will take countless of hours which can be spent elsewhere.

You overestimate the willingness and ability of the average org to implement and support things like this on their own.

I do not, I recognize that they care far more about costs and don't mind throwing one developer at problems internally than outsourcing it to a middleman of a middleman who is overcharging just for access to an API that isn't theirs.

Reminder, it's going to get easier to implement things. It is going to get easier to support things. Neither of these two reasons are going to be the catalysts they used to be for businesses anymore.

It's effectively a tiny frontend, doing 0.01% of the work, which is attached to another (highly available) product.

The usual knowledge about evaluating products applies.

If you go to the website of markprompt the people who made it already appear to be accomplished entrepreneurs, having worked on something called Motif, which I hadn't heard of but appears to be legit.

They also have a nice website and everything I read makes it sound like they know what they're doing.

These don't count for much but they count for something. I haven't investigated them much but I think this should be assessed like any other startup product.

The way it went is: we built this as part of Motif for the past month, and our users loved it. Many asked for a way to add this feature to their existing sites, so we made a standalone platform that streamlines the process, and open sourced it :)

Cool webUI. Why is it not on Motif main site? https://motif.land/

How are the embeddings created? How does it scan, index and find the appropriate information to feed to the prompt?

Embeddings are created using OpenAI's ada model. They are stored in Supabase with the vector extension, which offers a simple way to compute vector similarities. Then the associated sections are added to the prompt context.

Supabase looks awesome, thanks for that.

Reply on news.ycombinator.com