To summarise the article if you're skipping to the comments, the pgvector allows you to create a "vector" type in your database

    create table documents (
      id bigserial primary key,
      content text,
      embedding vector (1536)
    );
 

Then you can use OpenAI's Embedding API[0] to convert large text blocks into a 1535-dimension vector, which you will store in the database. From there you can used pgvector's cosine distance operator for searching for related documents

You can combine the search results into a prompt, and send that to GPT for a "ChatGPT-like" interface, where it will generate an answer from the documents provided

[0] https://platform.openai.com/docs/guides/embeddings

> From there you can used pgvector's cosine distance operator for searching for related documents

How does this scale with the number of rows in the database? My first thoughts are that this is O(n). Does the pgvector have a smarter implementation that allows performing k-nearest neighbor searches efficiently?

locality sensitive hashing is the typical method here. You generate a ton of random vectors. These vectors automatically give rise to infinite hyperplanes (the one they are normal to). Each vector/hyperplane is associated with a bit in the final hash. Then, each input vector is hashed by setting the bit if it's on one side of the hyperplane or unsetting it if it's on the other. The hamming distance between two vectors is now correlated with the cosine similarity. Or something like that.

That's the reason I come to HN every day. Thanks for the explanation, which probably could not be more compact.

That’s so smart! I read stuff like that and I’m just in awe of the cleverness.

You can add indexes per distance function to perform fast approximate nearest neighbor search: https://github.com/pgvector/pgvector#indexing

They mention this paper in the references: https://dl.acm.org/doi/pdf/10.1145/3318464.3386131

They describe optimizations here as well: https://simonwillison.net/2023/Jan/13/semantic-search-answer...

Does this replace pinecone?

Specialized databases will always outperform Postgres, which is a "jack of all trades". It really depends on your use-case, but I imagine if you need anything beyond basic vector support then Pinecone is a better option.