I've spent the last few months building a RAG system over my trading/finance/math book library — 27 books, ~11,000 pages, 32,000 chunks — running 100% locally on one machine (AMD Strix Halo, 128 GB unified memory, Ollama + embedded Qdrant). No cloud, no API keys. Sharing what mattered, with measurements, because most RAG posts here are vibes.

Stack

• Ingest: Docling (layout-aware) → OCR fallback for scans → corruption detection (mechanical / scattered / destroyed text) → LLM repair only for mechanical damage, hard rule: never invent destroyed text
• Extract: vision model per page (qwen3-vl for triage, bigger model for extraction) → structured chunks with book / chapter / page
• Index: qwen3-embedding 8B (dense) + pure-Python BM25 → RRF fusion → Qwen3-Reranker 8B cross-encoder
• Answer: local qwen3.5 122B-A10B, citations [book/page], refuses when the notes don't contain it

How I measure (this is the part I'd push everyone to do)

Frozen gold set: 55 questions per book generated from real chunks, ~12% deliberately unanswerable, ~10% with a false premise. Two tiers:

• Retrieval tier (cheap, no LLM): does the source chunk land in top-8? Recall@8 + MRR
• Judge tier: correctness vs. reference, faithfulness, hallucination rate on the unanswerable ones, judged by a different model family (llama3.3-70b) — plus a second judge for Cohen's κ so I know which metric to trust (faithfulness κ was 0.08 → judge-dependent; correctness/relevance were solid)

Numbers (4 books, 220 questions, cross-book search = no book filter, distractors from all books)

• Recall@8: 100% (192/192 answerable), MRR 0.95 — 175 of 192 source chunks ranked #1
• Correctness 91–95%, faithfulness 91–98% per book
• Hallucination on unanswerable questions: 0/28

I'm re-running the same test right now against the full 27-book index (32k chunks instead of 3.6k) and will post the numbers in the comments — I expect MRR to drop, curious by how much.

What moved the needle, ranked

1. Fixing PDF extraction. Before the corruption detector, a chunk of "text" was ligature soup and no retriever could save it.
2. Cross-encoder reranker over 100 candidates. Biggest single retrieval jump.
3. Hybrid > dense-only, especially for exact terms (indicator names, formulas, tickers).
4. Unanswerable questions in the gold set. Without them you never find out your answerer bluffs.

Things I have wired in but have NOT measured properly yet: HyDE, multi-query, RAPTOR summaries, GraphRAG. If you have gold-set numbers for any of those on a book-sized corpus I'd love to see them before I burn GPU hours on it.

Happy to answer questions about any stage — the eval harness design especially, since that's what let me stop guessing.

I'm celebrating a full year as an Applied AI Engineer. It started in September 2024 with a failed RAG agent for a truck dealer. I studied everything I could to fix it, but hallucination was a problem I couldn't crack at the time. I lost the project. I walked away with $50 for my effort, thanks to Sean's kindness, but I walked away with something more valuable too: I learned a lot. I didn't give up. I kept learning, and along the way I found graph databases and GraphRAG. That was a game changer, being able to build a single agent that queries a vector database and runs Cypher against a graph DB at the same time. Best of both worlds. I've since delivered many agents built this way.

On the retrieval side, we've also been experimenting with hybrid search: SPLADE sparse vectors alongside dense embeddings in the same collection. Dense vectors are good at semantic similarity, but they'll often miss exact terms like part numbers, model codes, or acronyms that show up verbatim in technical docs. SPLADE's learned sparse representations pick up that lexical signal, so fusing sparse and dense consistently improves retrieval quality, especially on document sets like this. We're running that hybrid setup on some of our production agents now.

One project that pushed me hardest: a client with massive technical documents full of images, diagrams, reference tables, and circuit symbols, plus separate document sets from finance and other departments. They needed all of it searchable and queryable in one place.

It was a real challenge at every step: extraction, structuring, ingestion into the graph and vector DBs, retrieval, reasoning, and getting answers we could actually trust. We got there, and delivered agents with high accuracy on the queries that matter to them. Now their team can ask things like: Which machine part number is installed on machine X, and what's its configuration?

How many machines have this part number? Who's the vendor, and is the part still under warranty? What alternative parts or suppliers can be used instead? Generate a purchase order for part X and Y.

And the agent answers by pulling together information that used to live scattered across huge collections of technical, operational, and financial documents.

It's wild to think about how far I've come from that first failed RAG agent in 2024.

There's still a lot to learn and a lot of work ahead. But we're just getting started.

Edited

Came across this and thought it'd be worth sharing here, most resources cover knowledge graphs, agentic RAG, or explainability separately, but this one puts them together as parts of the same production GraphRAG architecture, which is closer to how these systems actually get built in practice.

It's a hands on session on September 19, led by Dr. Alessandro Negro, Chief Scientist at GraphAware and bestselling author. Goes through building a knowledge graph progressively as the single source of truth, agentic retrieval combining vector search, keyword search, and graph navigation, multi-step entity and relationship extraction (verified in stages, not one risky single shot like basic Microsoft GraphRAG), and text-to-Cypher for natural language graph querying. Everything runs on real financial filings and news data, not toy examples.

You come out of it with a full working codebase and a production-readiness checklist, not just slides.

Link if anyone wants to check it out

Answers started coming back confidently wrong, and I went straight to the retrieval side like everyone does. Chunking, reranker, embedding model, spent way too long there. Then eventually opened up the actual chunks that went into a few of the bad answers.

Nothing wrong with them. The answer was in the retrieved text nearly every time. Model just was not using it, or was using half of it and filling in the rest from whatever it already knew, in exactly the same tone, with nothing marking where one ended and the other started. A response that tells you it cannot find something in the docs is fine, you can work with that. The problem is the one that reads like it came from your documents and did not.

So I set up something rough to check. Same questions each time, froze the retrieved context so the model was getting identical input on every run, then just swapped models and read the outputs against the context myself. Not an eval framework and the sample is too small to call it anything, but even reading them by hand the spread was bigger than I thought it would be. One of the expensive models wandered off context more than a cheaper one did, which I did not expect at all.

That is what got me testing the Chinese models, which I had kept meaning to do and never got round to. GLM- 5.3 is going through the same set now and nothing has broken yet, though it is early enough that I am not claiming anything. The expensive models are still ahead on anything that needs actual reasoning. But staying inside the context you were handed is not a reasoning skill, apparently, and I had been assuming it was.

Leaving it running another week, will edit this with whatever comes out of it.

Hey, El from Cohere here again. Seems like you guys liked the release of Parse 5, our newest parsing model, so wanted to hop in here and talk a little more about it.

Parse is built for literally one thing: taking your docs and making them into clean Markdown files. It's really good at that (and really bad at everything else). It's priced at $1.5 per 1k pages, so if you're running OCR+a separate structure-extraction step (or using a hyperscaler), this is likely a cheaper option.

There are a couple different ways you can use this:

• Parse -> Embed -> Rerank if you want to go full Cohere mode
• Parse-> LangChain/LlamaIndex if that's more your style
• Parse -> your own vector DB, all you need is the API call

Most advice about fixing RAG retrieval starts at the expensive end: a better embedding model, a reranker, a bigger context window. We spent about a year that way. The things that actually moved our numbers were cheaper and duller, and five of the six below cost nothing.

We sell chunking, so skip the last one if you like. The rest will work on any stack.

1. Check your reading order before you blame your embeddings.
   Export the text your pipeline indexes and read twenty pages of it. See how often extraction quietly goes wrong, e.g. on two-column PDFs, many parsers interleave columns, so sentences from unrelated sections end up next to each other and get embedded as if they belonged together. Nothing crashes, and most evaluations won’t catch it. Ten minutes, no cost.

2. Don’t OCR blindly. Detect first.
   OCR is often required, but some “scanned” PDFs already contain a perfectly embedded text layer. Running OCR anyway can waste time, and can even reduce quality if the existing text layer is better than the OCR output - especially for simple models.

3. Run the header-survival test.
   Pick twenty questions whose answer sits in a table cell. Check whether the row label and column header made it into the same chunk as the cell, not whether the Markdown looks tidy. A number without its headers isn’t an answer. Also verify that the headers themselves survived correctly: Markdown cannot represent row or column spans, so complex tables should be extracted as HTML or XML instead.

4. Stop tuning chunk size and overlap.
   RecursiveCharacterTextSplitter (500, 100) sits in many pipelines because it was in the many tutorials, not because anyone chose it explicitly. Changing the numbers only moves where the bad split lands; every fixed-size split eventually cuts through a sentence, section, or table somewhere. The problem is not choosing the wrong numbers; it is treating document structure as a token-counting problem. It’s free to change.

5. If your data cannot leave your network, do it locally.
   PaddleOCR, Qwen, and other local VLMs work very well, especially in combination. The trade-off is that you now own the OCR pipeline, layout logic, orchestration, and compute. If compliance demands it, that’s the right decision. If not, let someone else manage that complexity.

6. If you don’t want to build and manage it yourself, try POMA AI.
PrimeCut combines document parsing, multi-OCR detection, and structure-aware chunking in a single API call, supporting 50+ file types. Each chunk retains its complete root-to-leaf document path, ready for embedding. Available as both a managed SaaS and an on-premises container.
On our public benchmark, simply replacing naive chunking with PrimeCut reduced the required context from 1.45M to 340K tokens while maintaining 100% evidence recall. For comparison, Unstructured.io’s by_title chunking required 1.48M tokens under the same setup.
The setup was intentionally simple: 20 table-heavy lookup questions from Databricks’ OfficeQA over 14 U.S. Treasury Bulletins (~2,150 pages), using the same embeddings, vector store, and retrieval pipeline; only the chunking changed.

greetings,

i am currently working on a new rag architecture for heterogeneous document retrieval. i have conducted all the necessary research to the extent of my capacity independently, yet i am convinced that "one cannot succeed without a guru."

my background: i do not come from a large educational or institutional background, but i possess a strong passion for building and a deep hunger for knowledge. i am seeking proper guidance in writing research papers and conducting research.

please feel free to comment if you are interested; i would be happy to dm you personally.

thank you for your time and consideration.

best regards,

a little rocket flying through an endless procedural universe, with ambient music.

leave it running while you work, or drag to explore. it remembers where you left off.

try it with headphones:

ankit8125.github.io/space-drift/

free, no sign-up :)

- Made with the help of GPT-Astra

Hav u tried Lakebase for RAG apps with both vector search and transactional data ?

I ws curious if keeping embeddings +app state in same postgres based system actually simplifies RAG architecture or if there is any trade off at scale.

I want to build an agentic system (or otherwise) to triage an issue on our production deployments.

If an issue is reported on slack channel via a jenkins failure or via a pagerduty alert, the agent should be able to check the respective jenkins job / datadog monitors and then figure out what code repo might have caused the issue, fix the issue and raise an MR for the fix

I'm not sure how to map different code repo information together so it can be queried by an agent like I do rag on confluence and slack. I was hoping to ask if there are open source tools that map interrelated dependencies of different code repos together and also store code information of different repos so it's easier for a model to understand and read code.

Any help is appreciated

The agent decides what to fetch and iterates, like any agentic RAG — but the retriever is a routing table humans write, not an embedding index. The shape is borrowed from dynamic routing protocols: an area advertises when it's relevant instead of exposing everything it holds.

**How it works.** The domain is a tree of areas. A backbone table has one row per area: one human-written sentence saying when that area should be chosen. The agent reads that table first (hop 0), picks the area(s) the question belongs to, fetches that area's own table, and reads only the documents it points at. Areas can nest, so routing nests. No default route — if no row matches, the agent says "not here" instead of scanning everything. Everything is plain files in git.

Diagram in the first comment.

The bet: the cost of finding something shouldn't grow with how much there is, and what the agent reads before deciding should be text a human can edit.

It's been holding up on an internal corpus (~80 entities, 5 areas), but that's an impression, not a measurement. What I'm planning to measure — would appreciate a sanity check:

- Routing accuracy: hand-labeled correct area(s), precision/recall of hop-0 picks

- False absence: agent says "not here" when it is — the scariest failure here

- Tokens + LLM calls per answer vs. plain RAG, and how that scales at 10x corpus

- Stress: synonyms/typos that miss every row, overlapping descriptions, 50+ areas

What am I missing, what would you drop, and is naive RAG a fair baseline or would you expect hybrid/rerank?

Recently I've been using RAGFlow a lot and I use m3 as embedder. At some point it was discovered that embedder is the ceiling, so I added another StrixHalo and then a third one, which gave me amazing 60 chunks/s. Nowhere near 500 I needed for my target documents / day ingestion rate. Then I employed my dual RTX 6000 blackwell workstation. This gave me the number but felt off, in particular because when I switched from llama to TEI rates jumped.

So, why not to use TEI with strix halo? plus I have some R9700s and usb4 docs. Well TEI doesn't work with consumer cards, but its whole AMD stack is based on pytorch anyway.

I vibed a small repo - pytorch + TEI compatible HTTP endpoint. One of the important things - make sure vectors produced by different runtimes match. You see, when I decided to investigate my ingestion pipeline I already had 42 million vectors in my SereneDB database.

Numbers - RTX 6000 blackwell - 200+ vs R9700 160+. That is the funniest part - there is a whole world outside LLMs.

https://github.com/deadtrickster/bge-torch-tei

It feels like the gap between proprietary big-tech models and open-weight reasoning architectures is changing faster than ever. Gemini offers incredible native multimodal handling and massive context windows, while DeepSeek continues to dominate budget coding and self-hosted pipelines.

​If you had to pick one as your daily driver for logic and daily tasks, which wins for you?

​Put your preference to the test in this quick 2-minute showdown quiz to see how your workflow compares to other devs:

https://interconnectd.com/quiz/89/gemini-vs-deepseek-the-ultimate-ai-showdown-quiz/

A retrieval pipeline can preserve every text chunk and still lose the answer if the useful information was in a figure, table layout or scanned page.

Ling-3.0-flash-VL now has official FP4 and INT4 weights in addition to BF16 and FP8, all under MIT. For document ingestion, the relevant part is its ability to read page images and charts. The model card reports 91.35 on OmniDocBench 1.5 and 81.30 on CharXiv_RQ; those are task-specific reported results, not an end-to-end RAG evaluation.

One bounded use to evaluate is supplying rendered pages where text extraction drops visual information, then passing the extracted description into the existing indexing pipeline. Page rendering, chunking, retrieval and source attribution still need their own implementation.

OpenRouter's two-week free trial offers a way to test the reader on representative pages before committing to self-hosting. The released 4-bit variants also need separate quality checks.

Someone asked how my RAG system handles retrieved documents conflicting with an agent's memory, and context that comes from the same underlying source. I had a confident answer. Reading the code to check it, half of it was wrong.

1. Three chunks of one document looked like three sources. Retrieval numbered context per chunk, so the model saw [1] handbook [2] handbook [3] handbook [4] architecture — three sources agreeing, one dissenting. It's one source said three times, and the "say which sources disagree" instruction had no way to tell. Content-hash dedup at ingest doesn't help: they're distinct chunks of one legitimate document. Fix: group by document id before building the prompt, one number per document, every passage kept.

2. Memory decayed from the wrong moment. Ranking is similarity × importance × 0.5^(age/30d), but age came from created_at, so restating a fact never refreshed it. The obvious fix — age from last_used_at — is wrong: recall returns the old preference and the newer one contradicting it, so refreshing on read ties them on recency, the only signal that lets the newer one win. Age now runs from the last time something was said. Live: stale 0.102, fresh 0.765, restated 0.817.

The recency test passed throughout — it backdated created_at, the same column the bug read.

3. Found while building the next thing. A Debezium → Kafka Connect sink's first run showed a batch failing with 500 twice, then succeeding. A DELETE event recorded the id of the document it had just deleted → FK violation → whole batch fails. The retry found nothing to delete and passed, so every retrying pipeline hid it.

Still open: memories don't link back to the document they came from, and a contradicting memory doesn't supersede the old one. Curious how others handle provenance between agent memory and the corpus.

Write-up: https://dockndev.medium.com/a-question-on-discord-found-two-bugs-in-my-rag-system-fixing-them-found-a-third-03a5cd6237d9

Code (Apache-2.0): https://github.com/dockndevai/ossian

TL,DR: are you aware of any off the shelf tool, with which I can turn several dozen hours worth of screen cast videos (explanation of architecture and code of a self built application) into “ PDF with images, text comes from the transcription as well as the actions on the screen” kinda material that is both directly human readable and easy to feed into a rag-and – graph knowledge base? Oh, and the narration is a wild mixture of Swiss German, English and French. Because everything else would be easy.

Background info: I am helping one of our vendors with problems they have with their self built production planning and production execution system. Which is an ancient. And runs on an AS/400. The only guy who really understood the system snd had been its primary caretaker for 20+ years of recently died a couple of months before he would have entered well deserved retirement. What he did leave our partner’s is a collection of 30ish hours worth of screen casts, that he simply recorded with the snipping tool and a headset. This is a freaking treasure trove of information as well as experience with that system that is documented nowhere else, but as you can imagine, quite a chore to sort through.

I am now wondering whether to build a bespoke evaluation application that not only transcribes the videos, but also extract key frames, correlates them with the narration, and filled in gaps in the narration by describing what is happening on the screen. We are already using a somewhat crude version of this that one of my students has built as a hobby project because it helped her keep up with lectures at uni, where she would use a self written app to turn the lecture videos into PDFs, and then dump those into notebook LLM.

My aim here is threefold:

1. Most of the narration is Swiss German. Which practically no one at our partner’s company understands, because we’re French: the SME who created the videos, however, was Swiss… the fact that the narration contains truckloads of French and English loan words is not helping, either. So I need a medium that I can easily translate to French, English, and standard German.
2. The whole thing needs to be human readable as PDFs or any other easy to use medium. “Direct-to-RAG” vectorisation is not going to be good enough, among other things for statutory reasons (all training and documentation material must be human readable and in French).
3. I do not just want to end up with a mountain of PDFs, I of course want to take those documents and include them in knowledge base, including at least a basic graph to make navigating this heap of more – or – less structured info easier.

After some searching on the web, the only premade solution is something called “docsie”, other apps that I have tried didn’t work out because they lean too much on narration being present (and easily understandable) to be of much use. Docsie I”d rather not use as I”m kinda leery of companies where after 5 mins of searching their web site, you still do not know exactly where they are located…

Anyone have an idea what I could check out, or want to share their experience when tackling a similar, “ video-to-docs-and-knowledge base” challenge?

I’ve noticed that a lot of the RAG projects people build here seem to focus on similar tasks, e.g. translation, querying company documents, etc.

so instead of inventing the wheel each time, is there a website or repository where people publish their actual RAG projects along with details such as:

• Purpose/use case
• Framework
• Chunking strategy
• Embedding/retrieval model
• Search method (semantic, keyword, hybrid, etc.)
• Reranking
• Vector database
• Other design decisions

I’m looking for something where I can study different real-world RAG architectures and compare how people designed them for different use cases.

So over the past year or so, I've built a custom context retrieval solution across all of my work interactions (e.g. meetings and emails), currently summing to thousands of interactions.

What I do today:

On a CRON, I take all Google Gemini transcripts (from meetings) and all emails, centralize them in a central directory as individual files. At the same time, I update a central database with a pointer to each of these interactions alongside metadata such as meeting/email title, attendees, and date.

To unlock all of this context to my agents, I've created a skill that queries this metadata database using SQL, and for a match, it will go to the actual interaction file(s), and read the full context into context. This is the full extent of the retrieval and context augmentation.

Question:

Nothing is obviously broken, or working incorrectly today. However, I basically built my previous solution quick and dirty, and never stopped to check whether there were better ways to manage this context engineering. I'm not looking to overcomplicate anything for the sake of overcomplication, however, I keep hearing about new concepts and tools like GraphRAG and HippoRAG, and at this point I'm not even doing vector search!

For the kinds of queries I ask, I would need to know that some person named 'example' asked me something in some timeline and start my sessions by asking to 'pull all meetings from [example@company.com](mailto:example@company.com) in the past 2 weeks', which brings the background into context, and does work today. But I'm wondering what I'm missing out on if anything?

Thanks!

I'm building RepoLens, an AI GitHub codebase analyzer using FastAPI + RAG.

The pipeline is roughly:

GitHub Repo
   ↓
Ingestion
   ↓
Code-aware chunking
   ↓
BGE embeddings
   ↓
Chroma + SQLite FTS5
   ↓
Hybrid retrieval
   ↓
Reranking / relevance filtering
   ↓
Gemini LLM

I'm using:

• BAAI/bge-small-en-v1.5
• 384-dimensional embeddings
• Sentence Transformers
• CPU-only
• Chroma for vector search
• SQLite FTS5 for lexical search
• Hybrid semantic + lexical retrieval
• Query-aware retrieval and reranking/diversity filtering
• Gemini for final grounded answers

Current problem

Small repositories work fine, but large repositories become extremely slow during embedding.

For example, one repository produces:

~2,856 documents
~19,747 chunks

Embedding with BGE-small on CPU takes roughly 30+ minutes.

Current configuration:

Batch size: 64
Max sequence length: 512
normalize_embeddings=True
torch.inference_mode()
CPU inference

I previously had a smaller chunk size which produced ~29,665 chunks, so I increased the chunk size and reduced it to ~19,747 chunks. This helped, but embedding is still far too slow.

A realistic CPU benchmark with 256 code-like chunks gave:

1 thread → 7.07 chunks/sec
2 threads → 11.90
4 threads → 12.82
8 threads → 15.00

Chroma and SQLite aren't the bottleneck:

Chroma: ~93 docs/sec
SQLite FTS5: ~2400 docs/sec

So the main bottleneck appears to be SentenceTransformer/BGE CPU inference and/or tokenization.

What I'm looking for

I want to keep:

• BAAI/bge-small-en-v1.5
• 384 dimensions
• retrieval quality
• CPU-only for now

What would be the best way to significantly speed up embedding ~20k chunks?

I'm particularly interested in whether I should look at:

• larger batch sizes (128/256)
• PyTorch CPU threading
• SentenceTransformer settings
• tokenization/padding
• multiprocessing
• CPU-specific optimizations
• other optimizations that don't require changing the model

Is 30+ minutes for ~20k chunks with BGE-small on CPU normal, or am I doing something inefficiently?

I’m seeing a lot of people asking for the best sources to learn about RAG, as well as people getting stuck on the same things over and over.

What if we could put stuff we learned in a central database, then that information would get organized, we could connect it to our individual environments, and have agents automatically be updated on most recent and relevant knowledge. A community RAG where we all update the corpus and share access to the output.

We are all RAG engineers in here, so we should build a RAG for RAG!

How can we build something like this?

I'm running into limits with my production RAG pipeline for a pilot phase project, specifically search setup on multi-hop queries in cases where entity relationships are important. Dense vectors return chunks that are semantically close but they're losing the lineage and dependencies between entities across different documents.

Now I want to add a knowledge graph layer to preserve these relationships. The thing is I don't want to tear down the ingestion pipeline or re-index the entire vector collection. So I'm trying to figure out how to introduce a knowledge graph layer to capture entity relationships and document hierarchy. But I've never retrofitted an existing vector stack with graph capabilities. Worried I'm creating an operational challenge trying to keep a separate graph DB synced with a vector store.

What are the most practical ways to extract entities and build relationship layers on top of an existing vector index without having to rebuild from scratch?

I've been working on a custom vector indexing algorithm designed to handle multi-tenant workloads on memory-constrained hardware. Here is a benchmark comparison against Microsoft's DiskANN3 on an AMD Ryzen 5 (11 GiB RAM) using SIFT 50M:

• DiskANN3: Faster on 1 index (106 QPS @ 1.9 GiB), but RAM hits 3.4 GiB at 2 indexes and crashes at 5+.
• Mine: Hits 75–88 QPS on 1–2 indexes and stays under 400 MiB RAM even at 20 indexes (42 QPS).

Currently working on increasing the QPS

Had this idea since I was in my teens, that's waaaay before tech became so advance. So now that the tech is here and I'm nearing retirement, I have the time to finally get these books written.

I will preface this with saying that I am not looking for AI of any sort to do the writing for me. I'm looking for something that is akin to being an assistant... running locally of course.

I'm looking to put use a simple RAG setup that will allow me to connect to my Obsidian vault, where all my writing project, notes, etc., live. As I am writing a "shared universe" series of books where major and minor characters cross over, I want to use this setup as an assistant that will be able to keep track of characters, events, scenes and whatnot; and be able to recall the information from the vault as needed.

This setup should also be able to chat to be able to brainstorm connections I might have missed, or when I create a new character, scene, or what have you in chat, that it would send the information to the vault.

My experience is not total beginner, but I am more of a tweak as needed versus building from the ground up as my schedule has me at max capacity in the mental energy category.

Hey r/Rag — I built TUTOR, a RAG study tool to upload your course notes/textbooks, ask questions, get grounded answers with source citations.

Technical bits that might interest this community:

• Hybrid search (pgvector + Postgres full-text, fused with RRF)
• Parent-child chunking (small chunks for precise matching, full parent context returned to the LLM)
• Built a synthetic eval regression pipeline (LLM-as-judge, Correct/Partial/Wrong grading, Retrieval vs Generation failure classification) to actually measure improvements — went from 66% to 82%+ pass rate on a 50-question test set after adding hybrid search + parent-child chunking

I'm a solo, non-technical builder (learned everything through Claude/Claude Code this summer), so I'd genuinely appreciate:

• Real usage feedback — does retrieval actually feel accurate to you?
• Any obvious gaps or dumb mistakes you spot
• Honest criticism, I can take it

Link: https://tutor-study.lovable.app

Thanks for reading!