Re:Ingesting PDFs and why Gemini 2.0 changes everything
by thelittleone on Wednesday February 05, 2025 @04:26PM
(#42955403)
Fixed size chunks is holding back a bunch of RAG projects on my backlog. Will be extremely pleased if this semantic chunking solves the issue. Currently we're getting around an 78-82% success on fixed size chunked RAG which is far too low. Users assume zero results on a RAG search equates to zero results in the source data.
[ Parent
| on HN ]
Re:Ingesting PDFs and why Gemini 2.0 changes everything
by jacobr1 on Wednesday February 05, 2025 @06:43PM
(#42957023)
Also consider methods that are using reasoning to potentially dispatch additional searches based on analysis of the returned data
Re:Ingesting PDFs and why Gemini 2.0 changes everything
by refulgentis on Wednesday February 05, 2025 @04:46PM
(#42955675)
FWIW, you might be doing it / ruled it out already:
- BM25 to eliminate the 0 results in source data problem
- Longer term, a peek at Gwern's recent hierarchical embedding article. Got decent early returns even with fixed size chunks
Re:Ingesting PDFs and why Gemini 2.0 changes everything
by thelittleone on Wednesday February 05, 2025 @04:53PM
(#42955786)
Much appreciated.
For others interested in BM25 for the use case above, I found this thread informative.
Re:Ingesting PDFs and why Gemini 2.0 changes everything
by mediaman on Wednesday February 05, 2025 @05:10PM
(#42956001)
Agree, BM25 honestly does an amazing job on its own sometimes, especially if content is technical.
We use it in combination with semantic but sometimes turn off the semantic part to see what happens and are surprised with the robustness of the results.
This would work less well for cross-language or less technical content, however. It's great for acronyms, company or industry specific terms, project names, people, technical phrases, and so on.