Live data from Hacker News

Show HN: PageIndex – Vectorless RAG

github.com

81–90 of 147 posts

Re: Show HN: PageIndex – Vectorless RAG

#81
post #17

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.

The idea this person is trying for is a LLM that explores the codebase using the source graph in the way a human might, by control+clicking in idea/vscode to go to definition, searching for usages of a function, etc. It actually does work, other systems use it as well, though they have the main agent performing the codebase walk rather than delegate to a "codebase walker" agent.

Re: Show HN: PageIndex – Vectorless RAG

#82

This 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?

Tree search hasn't replaced vector search, you can use them synergistically, it's just that vector search is "fiddly" as you have to set up a bunch of stuff to index your repos, manage embeddings, etc and it can use a lot of disk space if you don't use graph representations for your embeddings like LEANN.

Re: Show HN: PageIndex – Vectorless RAG

#83
post #65

The 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…

Extracting structure and elements from HTML should be trivial and probably has multiple libraries in your programming language of choice. Be happy you have machine-readable semantic documents, that's best-case scenario in NLP. I used to convert the chunks to Markdown as it was more token-efficient and LLMs are often heavily preference trained on Markdown, but not sure with current input pricing and LLM performance gains that matters anymore.

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

#84

Looks like this should scale spectacularly poorly. Might be useful for a few hundred documents max though.

This design isn't new, Codanna MCP uses it, and it definitely works (at least when run by the main agent, a dumb subagent might biff it).

Re: Show HN: PageIndex – Vectorless RAG

#85
post #65

The 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?

Oh, I totally think markdown is better than converting to png and then doing OCR. Maybe I did not use a good HTML to markdown converter. The HTML documents are really long and the markdown converter broke down a few times. But as I mentioned, this is probably on me as I did not do a good job of finding a better HTML to markdown converter.

Re: Show HN: PageIndex – Vectorless RAG

#86
post #73

an 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?

Faster is not always better. In certain situations, we may choose to sacrifice speed for increased accuracy.

Re: Show HN: PageIndex – Vectorless RAG

#87
post #69
post #65

The 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.

So you suggest working directly with HTML or going HTML -> Markdown first?

Re: Show HN: PageIndex – Vectorless RAG

#88

Context 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 super automatable. DSPy can automate prompt generation that massively outperforms human prompts, and instead of hand packing context, you can use IR/ML algorithms to intelligently select the optimal context bundle to produce the desired output.

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…

[dead]

Re: Show HN: PageIndex – Vectorless RAG

#90
post #76
post #65

The 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 will try it out. Is this the correct library? - https://github.com/yobix-ai/extractous

I have used Gemini for OCR and it was indeed good. I also used GPT 3.5 and liked that too.

Post reply on HN