rahmansahinler1

Joined 3 years ago

Karma

Submissions

Member since

Nov 17

Recent submissions

Thank you very much! Yes, I agree we can kinda say everything is a vector database when you store vectors in it but what I meant by this is we don't need the use Pinecone or any other vector data bases for high performance, high accuracy and user information integration. We all made this with postgresql, redis and faiss. On the other hand, we didn't use pgvector mainly because we wanted to use Faiss as our primary vector search. Faiss gives us flexibilty to control the time for answer generation, with indexing method (tradeoff between accuracy and speed). And indexing with Faiss really fast and efficient.

RAG Without a Vector DB, PostgreSQL and Faiss for AI-Powered Docs

4 rahmansahinler1 1 year ago 2 comments

Comment · 1 year ago

I will try Obisidian for sure. But can we interactively do something with taken notes, like dragging them etc?

Comment · 1 year ago

This is mentioned, I liked the idea but it might be overkill to take simple notes. On the other hand interactivity while structuring the notes might be beneficial time to time. Like dragging them and observe them etc.

Comment · 1 year ago

I've never used it, but it seems mostly like a planning and productivity tool rather than note taking tool. I want to easily structure my notes like MS One Note, reach them with different devices and be able to semantically search through notes. Sometimes I forget how I took that note and couldn't find where did I put it.

Comment · 1 year ago

We've built Doclink.io, an AI-powered document analysis product with a from-scratch RAG implementation that uses PostgreSQL for persistent, high-performance storage of embeddings and document structure.

Most RAG implementations today rely on vector databases for document chunking, but they often lack customization options and can become costly at scale. Instead, we used a different approach: storing every sentence as an embedding in PostgreSQL. This gave us more control over retrieval while allowing us to manage both user-related and document-related data in a single SQL database.

At first, with a very basic RAG implementation, our answer relevancy was only 45%. We read every RAG related paper and try to get best practice methods to increase accuracy. We tested and implemented methods such as HyDE (Hypothetical Document Embeddings), header boosting, and hierarchical retrieval to improve accuracy to over 90%.

One of the biggest challenges was maintaining document structure during retrieval. Instead of retrieving arbitrary chunks, we use SQL joins to reconstruct the hierarchical context, connecting sentences to their parent headers. This ensures that the LLM receives properly structured information, reducing hallucinations and improving response accuracy.

Since we had no prior web development experience, we decided to build a simple Python backend with a JS frontend and deploy it on a VPS. You can use the product completely for free. We have a one time payment premium plan for lifetime, but this plan is for the users want to use it excessively. Mostly you can go with the free plan.