91–100 of 166 posts
I am surprised to see very few setups leveraging LSP support. (Language Server Protocol) It has been added to Claude Code last month. Most setups rely on naive grep.
LSP is not great for non-editor use cases. Everything is cursor position oriented.
It uses LanceDB and has dozens of different extraction/embedding models to choose from. It even has evals for checking retrieval accuracy, including automatically generating the eval dataset.
You can use its UI, or call the RAG via MCP.
Demo: https://app.dwani.ai
GitHub: https://github.com/dwani-ai/discovery
Now working on added Agentic features, by continuous analysis of Document with Generated prompts.
I made, and use this: https://github.com/libragen/libragen It’s a CLI tool and MCP server for creating discrete, versioned “libraries” of RAG-able content. Under the hood, it uses an embedding model locally. It chunks your content and stores embeddings in SQLite. The search functionality uses vector + keyword search + a re-ranking model. You can also point it at any GitHub repo and it will create a RAG DB out of it.…
Don't use a vector database for code, embeddings are slow and bad for code. Code likes bm25+trigram, that gets better results while keeping search responses snappy.
I've gotten great results applying it to file paths + signatures. Even better if you also fuse those results with BM25.
After some time we noticed a semi-structured field in the prompt had a 100% match with the content needed to process the prompt.
Turns out operators started puting tags both in the input and the documents that needed to match on every use case (not much, about 50 docs).
Now we look for the field first and put the corresponding file in the prompt, then we look for matches in the database using the embedding.
85% of the time we don't need the vectordb.
It uses PostgreSQL with pgvector, hybrid BM25, multi-query expansion, and reranking.
(It's the first time I share it publicly, so I am sure there'll be quirks.)
Anyone use these approaches with academic pdfs?
Anyone using them for electronics datasheets?
The problems with datasheets is tables which span multiple pages, embedded images for diagrams and plots, they're generally PDFs, and only sometimes are they 2-column layout.
Converting from PDF to markdown while retaining tables correctly seems to work well for me with Mistral's latest OCR model, but this isn't an open model. Using docling with different models has produced much worse results.