Not sure if I fully understand it, but this seems highly inefficient? Instead of using embeddings which are easy to make a cheap to compare, you use summarized sections of documents and process them with an LLM? LLM's are slower and more expensive to run.
Show HN: PageIndex – Vectorless RAG
81–90 of 147 posts
Re: Show HN: PageIndex – Vectorless RAG
#82This is like semantic version of B+ trees.
Yeah, I strongly agree. I also found in AI coding tools, tree search has replaced vector search. I’m wondering if in generic RAG systems, tree search will replace vector databases?
Re: Show HN: PageIndex – Vectorless RAG
#83The folks who are using RAG, what's the SOTA for extracting text from pdf documents? I have been following discussions on HN and I have seen a few promising solutions that involve converting pdf to png and then doing extraction. However, for my application this looks a bit risky because my pdfs have tons of tables and I can't afford to get in return incorrect of made up numbers. The original documents are in HTML for…
If you have scanned documents, last I checked Gemini Flash was very good cost/performance wise for document extraction. Mistral OCR claims better performance in their benchmarks but people I know used it and other benchmarks beg to differ. Personally I use Azure Document Intelligence a lot for the bounding boxes feature, but Gemini Flash apparently has this covered too.
https://getomni.ai/blog/ocr-benchmark
Sidenote: What you want for RAG is not OCR as-in extracting text. The task for RAG preprocessing is typically called Document Layout Analysis or End-to-End Document Parsing/Extraction.
Good RAG is multimodal and semantic document structure and layout-aware so your pipeline needs to extract and recognize text sections, footers/headers, images, and tables. When working with PDFs you want accurate bounding boxes in your metadata for referring your users to retrieved sources etc.
Re: Show HN: PageIndex – Vectorless RAG
#84Looks like this should scale spectacularly poorly. Might be useful for a few hundred documents max though.
Re: Show HN: PageIndex – Vectorless RAG
#85The folks who are using RAG, what's the SOTA for extracting text from pdf documents? I have been following discussions on HN and I have seen a few promising solutions that involve converting pdf to png and then doing extraction. However, for my application this looks a bit risky because my pdfs have tons of tables and I can't afford to get in return incorrect of made up numbers. The original documents are in HTML for…
Can you explain why to png? why not to markdown?
Re: Show HN: PageIndex – Vectorless RAG
#86an effective "vectorless RAG" is to have an LLM write search queries against the documents. e.g. if you store your documents in postgres, allow the LLM to construct a regex string that will find relevant matches. If you were searching for “Martin Luther King Jr.”, it might write something like: SELECT id, body FROM docs WHERE body ~* E'(?x) -- x = allow whitespace/comments (?:\\m(?:dr|rev(?:erend)?)\\.?\\M[\\s.]+)? -…
Won't that be slower than vector DB's by an order of magnitude or more?
Re: Show HN: PageIndex – Vectorless RAG
#87The folks who are using RAG, what's the SOTA for extracting text from pdf documents? I have been following discussions on HN and I have seen a few promising solutions that involve converting pdf to png and then doing extraction. However, for my application this looks a bit risky because my pdfs have tons of tables and I can't afford to get in return incorrect of made up numbers. The original documents are in HTML for…
If accuracy is a major concern, then it's probably guaranteed better to go with the HTML documents. Otherwise, I've heard Docling is pretty good from a few co-workers.
Re: Show HN: PageIndex – Vectorless RAG
#88Context and prompt engineering is the most important of AI, hands down. There are plenty of lightweight retrieval options that don't require a separate vector database (I'm the author of txtai [ https://github.com/neuml/txtai ], which is one of them). It can be as simple this in Python: you pass an index operation a data generator and save the index to a local folder. Then use that for RAG.
Context and prompt engineering are going to be replaced by algorithms, 100%.
Re: Show HN: PageIndex – Vectorless RAG
#89>"Retrieval based on reasoning — say goodbye to approximate semantic search ("vibe retrieval" How is this not precisely "vibe retrieval" and much more approximate, where approximate in this case is uncertainty over the precise reasoning? Similarity with conversion to high-dimensional vectors and then something like kNN seems significantly less approximate, less "vibe" based, than this. This also appears to be complet…
Re: Show HN: PageIndex – Vectorless RAG
#90The folks who are using RAG, what's the SOTA for extracting text from pdf documents? I have been following discussions on HN and I have seen a few promising solutions that involve converting pdf to png and then doing extraction. However, for my application this looks a bit risky because my pdfs have tons of tables and I can't afford to get in return incorrect of made up numbers. The original documents are in HTML for…
extractous is worth a look if it's real text If it's an image / you need to OCR it, Gemini Flash is so good and so cheap that I've had good luck using it as a "meta OCR" tool
I have used Gemini for OCR and it was indeed good. I also used GPT 3.5 and liked that too.