4 Comments
User's avatar
Vladimir's avatar

One problem with pg_vector hnsw index implementation is that fetches candidates based on distance **before** applying any other filters from `WHERE`. I would recommend checking lantern and ts_vector which are both faster and more precise.

Steve B's avatar

I did a similar project to learn more about LLMs to build a chat bot that is powered by an author's diary. I vectorized 40k of his journal entires, when you ask a question it queries for the top 10 related articles to use as context to answer your question. I found the process helpful to learn more about RAG and make LLMs more useful. More details here - https://stevebarbera.medium.com/building-rankobot-with-chatgpt-and-laravel-dd69088211d9

Yoyo's avatar

The point about embeddings feeling like regular deterministic code really landed for me. That’s exactly why they’re a friendlier on-ramp than LLMs for someone like me who’s still wrapping their head around the AI space. I’ve been experimenting with similar search features on a side project, and the mix of SQL and vector ops in pgvector is surprisingly approachable. If you’re looking for a quick way to test text similarity without spinning up a new service, I found LiteralKit (https://literalkit.com/superscript-generator) useful for some lightweight string tweaks, but embeddings are where the real depth is.