You're Doing RAG Wrong  🔗 **Source:** [You're Doing RAG Wrong](https://twitter.com/akshay_pachaar/status/2052743644411765230/?rw_tt_thread=True) > [!note]+ Document Notes > tags: [rag, retrieval-augmented-generation, vector-search, embeddings, knowledge-engineering, llm-infrastructure] > author: Akshay (@akshay_pachaar) > source: X (Twitter) > reference: https://twitter.com/akshay_pachaar/status/2052743644411765230 > date created: 2026-06-21 15:00 > > # 🏷️ Title: You're doing RAG wrong > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Blockify (Iternal Technologies)](https://github.com/) — the preprocessing layer the thread promotes (open-source; thread links a "try it yourself" URL). - [LangChain](https://www.langchain.com), [LlamaIndex](https://www.llamaindex.ai), [Haystack](https://haystack.deepset.ai) — orchestration frameworks the thread positions as downstream of the real problem. ## 📝 Summary - **What happened.** A technical Twitter thread by Akshay (@akshay_pachaar) argues that nearly every RAG pipeline rests on an unexamined assumption — that a *chunk of text* is the right unit of knowledge to embed — and that this upstream choice causes most retrieval failures people try to patch downstream with rerankers, hybrid search, and threshold tuning. - **Why it matters.** If the unit of embedding is wrong, no amount of retrieval-algorithm tuning fixes it. The thread reframes RAG quality as a *data-modeling* problem, not a search-tuning problem, and proposes embedding a "question-answer packet" (one validated claim plus typed governance fields) instead of a prose window. - **Key stakeholders.** Enterprise RAG teams (especially those with versioned, access-controlled corpora across SharePoint/Confluence/Git), vector-DB and embedding vendors, and Iternal Technologies, whose Blockify product implements the proposed "IdeaBlock" unit. - **Risks and tradeoffs.** The headline metrics (40x corpus reduction, 3x fewer tokens, 2.3x relevance, 13.55% accuracy lift) all come from one vendor's internal 17-document benchmark — unsourced, unreproduced, and marketing-shaped. The pipeline adds a preprocessing/distillation layer (LLM cost, human SME validation, dedup tuning) before the vector store. - **Bottom line.** Fix the knowledge unit, not the retrieval algorithm: embed atomic question-answer claims with governance metadata, deduplicate to canonical blocks, and the retrieval surface sharpens. The claim is plausible and well-argued; the numbers need independent verification. ## 📖 Main Content - **The core thesis.** "A chunk of text is the wrong unit of knowledge to embed." Chunkers split on token count, so a chunk is a *structurally neutral container* with no idea boundary, no version identity, and no access metadata. The model retrieving it can't know what's missing. - **Three failure modes traced to the chunk.** (1) *Idea fragmentation* — you retrieve half a table or a conclusion with no argument. (2) *Version collision* — enterprise corpora hold the same doc in a dozen near-identical versions; top-K returns five copies, current and deprecated mixed, and the LLM blends them into confident wrongness. (3) *No governance anchor* — access control gets bolted onto the orchestrator instead of living in the data. - **The proposed fix: the IdeaBlock.** Instead of a prose window, embed a *claim*: one question, its validated 2–3 sentence answer, and typed governance fields (clearance level, version state, source) on one object. Because user queries are already questions, matching a question to a stored answer becomes *structural*, not just semantic. - **Vector-geometry argument.** In Blockify's internal benchmark (17 docs, 298 pages), mean cosine distance from query to best block was 0.1585 for IdeaBlocks vs 0.3624 for naive chunks — a 2.29x reduction. - **Counterintuitive distillation result.** Less data, more accuracy: 2,042 raw IdeaBlocks deduplicated (80–85% similarity, 3–5 rounds) to 1,200 canonical blocks; word count dropped 88,877 → 44,537; the distilled set beat the undistilled by 13.55% on vector accuracy. Rationale: fifteen near-duplicates create fifteen competing vectors that split probability mass and depress the canonical match. - **The seven-stage pipeline.** Scoping (define Org > BU > Product > Persona hierarchy) → Ingestion (DOCX/PDF/PPT/images/MD/HTML → fine-tuned LLaMA 3 / QWEN 3.5 / Gemma → draft IdeaBlocks, 1,000–4,000 char input) → Chunking/extraction (context-aware, outputs Q-A pairs) → Semantic deduplication (cluster + merge via a second tuned LLM; GPU or Intel Xeon CPU) → Auto-tagging (clearance, version state, product line, export-control, privacy) → Human validation (5–10 SMEs, 1–2 hrs/quarter each) → Export (JSON-L or API to Azure AI Search / Pinecone / Milvus / Vertex; embeddings via OpenAI/Bedrock/Mistral/Jina/open-source). - **Application-layer payoff.** Query construction simplifies (question→answer match); governance moves into the data layer (a sales engineer and a legal reviewer query the same index but the *blocks* carry the access boundary); updates propagate from one record instead of hunting dozens of near-duplicates. - **The framing analogy.** "RAG stacks are beginning to grow a distillation layer between parsing and vectorization, the way web stacks grew a CDN layer between origin and browser." Build it yourself (clustering + LLM summarization + schema enforcement) or use Blockify. - **Contested/uncertain.** Every quantitative claim is vendor-internal and single-source. "Almost no one examines" the chunk assumption is rhetorical, not measured. The thread is also a product promotion for Blockify/Iternal Technologies, which is disclosed but shapes the framing. ### 🗒️ Notes - The unit-of-knowledge critique is the load-bearing idea: a chunk "knows nothing about where its ideas begin or end, which version of a document it came from, who is allowed to see it." - Splitter behavior is the mechanism: "the splitter cuts wherever the token count runs out" → fragmented retrieval. - Version problem is framed as enterprise-specific: same doc in a dozen near-identical versions across SharePoint, Confluence, Git → top-K returns deprecated + current mixed. - IdeaBlock = question + validated answer + typed governance fields on one object; "one fact per unit, nothing more." - Key reframe: "When your index stores answers to questions, the match becomes structural, not just semantic." - Geometry metric: 0.1585 vs 0.3624 cosine distance = 2.29x reduction (17 docs / 298 pages, Blockify internal). - Distillation: 2,042 → 1,200 canonical blocks; 88,877 → 44,537 words; +13.55% vector accuracy distilled vs undistilled. - Redundancy theory: near-duplicates "distribute probability mass" and pull down the canonical match score — "Your vector index isn't a hard drive you want to fill. It's a retrieval surface." - Pipeline is seven stages, each with defined I/O so "failures are localizable and reproducible." - Models named: fine-tuned LLaMA 3 / QWEN 3.5 / Gemma; dedup uses a second specially tuned LLM; GPU-optimized with Intel Xeon CPU fallback. - Governance becomes data, not orchestrator logic: clearance (PUBLIC/INTERNAL/CONFIDENTIAL/SECRET), version state (Current/Deprecated/Draft/Approved). - Single-record update propagation is the maintainability win vs "finding all of them, which at enterprise scale is not a tractable problem." - Underlying principle: "The chunk is a parsing convenience that became a retrieval assumption." The fix is "a better unit," not "a better retrieval algorithm." - CDN analogy positions the distillation layer as an emerging architectural tier. - Promotional close: "It's open-source! Try it yourself here→" plus a reshare CTA and the author's handle — marks this as content marketing, not neutral analysis. - **Headline metrics are unsourced vendor claims** — flagged in Fallacies below. ## 📚 References - [Blockify — Iternal Technologies](https://iternal.ai/) — the preprocessing layer implementing IdeaBlocks (thread states it's open-source with a "try it yourself" link). - [LangChain](https://www.langchain.com) - [LlamaIndex](https://www.llamaindex.ai) - [Haystack — deepset](https://haystack.deepset.ai) - [Pinecone](https://www.pinecone.io), [Milvus](https://milvus.io), [Azure AI Search](https://azure.microsoft.com/products/ai-services/ai-search), [Vertex AI Matching Engine](https://cloud.google.com/vertex-ai) — supported vector stores named in the thread. ## 🗣️ Paraphrase - Every RAG pipeline assumes a text chunk is the right thing to embed, and that assumption is rarely questioned even though it causes most retrieval failures. - A chunk has no idea boundary, no version identity, and no access metadata, so splitters cut mid-thought and retrieval returns fragments, mixed document versions, and ungoverned content. - The better unit is a question-answer packet — one claim, its validated answer, and typed governance fields — which matches the question-shaped queries users actually send. - Embedding atomic claims tightens vector geometry (smaller query-to-answer distance) and, counterintuitively, shrinking the corpus via deduplication *raises* accuracy because redundant near-duplicates stop competing for the same retrieval slot. - A seven-stage preprocessing pipeline turns documents into deduplicated, auto-tagged, human-validated IdeaBlocks exported to any vector store. - At the application layer this simplifies queries, pushes governance into the data, and lets a single record update propagate everywhere. - The real fix lives at the data layer, not the retrieval algorithm; build the distillation layer yourself or use Blockify. ## 📰 Newsletter **The unit problem nobody audits — RAG's quiet bug** Here's a spicy take worth your attention if you build anything with retrieval: maybe your RAG isn't failing because of your reranker or your embedding model — maybe it's failing because you embedded the wrong *thing*. Akshay (@akshay_pachaar) makes the case that a text chunk is a structurally clueless container: it doesn't know where an idea starts or stops, which version of a doc it came from, or who's allowed to read it. So your splitter hacks a table in half, top-K hands the model five near-identical paragraphs (one current, four deprecated), and the answer comes back confidently wrong. The proposed fix is elegant: stop embedding prose windows and start embedding *question-answer packets* — one validated claim plus governance fields right on the object. The thread cites big gains (40x smaller corpus, 2.3x tighter retrieval, +13.55% accuracy from deduplication), and the counterintuitive headline — less data, more accuracy — actually has a clean rationale: fifteen duplicate vectors split your match score, so collapsing them sharpens the signal. WordPress and open-data folks will like the framing: governance as typed data, not orchestrator glue. One honest caveat — every number here is a single vendor's internal benchmark (Blockify/Iternal), so treat the metrics as hypotheses, not gospel. Still, "fix the unit, not the algorithm" is a keeper. ## ✅ Action Items #### DevRel - Developer advocacy: build a talk/demo comparing naive-chunk vs claim-unit retrieval on an open corpus, with reproducible numbers (don't reuse vendor figures). - Education: workshop on "knowledge units in RAG" — chunking strategies, atomic claims, dedup thresholds. - Developer experience: publish a minimal reference repo that turns docs into question-answer packets using open tooling (clustering + LLM summarization + schema). - Developer marketing: clip the "chunk is the wrong unit" thesis as evergreen explainer content. - Community management: host an office-hours thread on RAG retrieval failures and fixes. - Internal/external/cross-project: share a benchmark harness so claims like "2.3x relevance" can be independently checked. #### OSPO - Policy & Governance: guidance on embedding access-control metadata in the data layer vs orchestrator. - License Compliance: verify Blockify's open-source license and any fine-tuned model weights' licenses before adoption. - Security Management: review PII/clearance handling when corpora carry typed governance fields. - Software Inventory: catalog distillation-layer tooling as a new RAG stack tier. - Developer Support: consultation on dedup-threshold tuning and SME validation workflows. - Community Engagement: fund an independent reproduction of the IdeaBlock benchmark. - Strategic Alignment: track "retrieval accuracy per token" as a measurable KPI. #### Community - Maintainers: Not applicable to this source — no specific OSS project maintainership is in scope. - Contributors: open a "first issue" to add a claim-unit example to an existing RAG library. - Sponsors: report reproduction results as an ecosystem-health signal. - Ecosystem: coordinate a shared, public RAG benchmark so vendor metrics can be contested. #### WordPress - Core: Not applicable to this source. - Core Performance: Not applicable to this source. - Core AI: note "embed atomic claims with governance metadata" as a pattern for any WP-side RAG/search feature. - **Core Program Team:** Not applicable to this source. - Mobile: Not applicable to this source. - Playground: a Playground demo could illustrate chunk-vs-claim retrieval interactively. - Community: meetup talk on RAG knowledge-unit design. - Training: learning path on retrieval data modeling for WP developers. - Marketing: Not applicable to this source. - Support: Not applicable to this source. - Design: Not applicable to this source. - Documentation: examples-first guide to structuring content as queryable claims. - Photos / TV / Openverse: Not applicable to this source. - Polyglots: glossary for "chunk," "IdeaBlock," "semantic distillation," "retrieval surface." - Accessibility: Not applicable to this source. - Meta: Not applicable to this source. - CLI: Not applicable to this source. - Hosting: Not applicable to this source. - Tide / Themes / Plugins: Not applicable to this source. #### The WPCC - Programs: Not applicable to this source — no community-funding angle in the thread. - Projects: Not applicable to this source. - Funding experiments: microgrant for an open reproduction of distillation-layer claims. ### FAIR - Technical independence: a self-hosted distillation layer with first-party governance metadata is a FAIR-aligned independence play. - Policies and covenants: transparency on which metrics are vendor-internal vs independently reproduced. - Productized governance artifacts: a schema spec for typed governance fields (clearance, version state) on knowledge units. ## 🧪 Hypotheses - H1: Embedding question-answer packets yields smaller mean query-to-answer cosine distance than naive chunking on the same corpus. - H2: Deduplicating near-identical knowledge units (80–85% similarity) raises top-K retrieval accuracy despite shrinking the corpus. - H3: Corpora with high version-redundancy (enterprise SharePoint/Confluence/Git) benefit more from claim-unit embedding than low-redundancy corpora. - H4: Moving governance fields into the data layer reduces access-control errors versus orchestrator-side filtering. - H5: The accuracy gains from claim-unit embedding are independent of the underlying embedding model and vector store. - H6: Single-record update propagation reduces stale-answer rate compared to multi-passage chunked corpora. ### 📊 Methodology - H1/H2/H5: controlled A/B retrieval benchmark on a *public* multi-domain corpus, holding embedding model and vector store constant, varying only the unit (chunk vs claim) and dedup on/off; report cosine distance, recall@k, and human-judged answer correctness with confidence intervals. - H3: stratify corpora by measured version-redundancy and compare gain magnitude across strata. - H4: inject access-control test cases and measure leak/false-deny rates for data-layer vs orchestrator filtering. - H6: longitudinal study tracking stale-answer rate after a known fact change, chunked vs claim-unit corpora. ### ❓ Questions - Does the claim-unit advantage hold on low-redundancy or narrative corpora, or only on redundant enterprise document sets? - What's the total cost (LLM preprocessing + SME validation) per accuracy point gained, versus just buying a better reranker? - How brittle is the 80–85% dedup threshold across domains, and who tunes it? - Does forcing knowledge into "one question, one answer" lose multi-hop or relational information that chunks preserve? ### 🔮 Future Research - Independent, reproducible benchmark of claim-unit vs chunk retrieval on open datasets (the thread's metrics are vendor-internal). - Failure-mode study: what kinds of knowledge resist atomization into question-answer packets? - Cost-benefit modeling of the distillation layer vs downstream retrieval tuning. - Interaction effects between claim-unit embedding and rerankers/hybrid search — additive or redundant? ### 💡 Implications - **Practice:** treat RAG quality as a data-modeling problem; audit the embedding unit before tuning retrieval. - **Policy:** typed governance metadata on knowledge units enables data-layer access control and auditability. - **Security:** clearance/version fields in the data reduce orchestrator-side filtering bugs but concentrate sensitive metadata in the vector store. - **Education:** curricula should teach retrieval data modeling, not just embedding/reranking mechanics. - **Funding models:** vendor-internal benchmarks shouldn't drive adoption; fund independent reproduction. ### 🧠 Learning Styles Assessment - Reading level estimate: dense technical prose with short declarative sentences; ~Flesch–Kincaid Grade 11–13 (specialist vocabulary: cosine distance, probability mass, IdeaBlock, semantic distillation). Flesch Reading Ease ~40–50. #### 👀 Visual learners - Present: none — plain-text thread, no diagrams or charts despite quantitative claims. - Improve: a chunk-vs-claim retrieval diagram, a before/after vector-space scatter, and a seven-stage pipeline flowchart with I/O per stage. #### 🔊 Aural learners - Present: none — text-only. - Improve: a 3–5 minute audio walkthrough of the unit-of-knowledge argument. #### 🗣️ Verbal learners - Present: strong analogies ("retrieval surface," "your vector index isn't a hard drive," CDN-layer comparison) and clear definitions of IdeaBlock. - Improve: a glossary callout (chunk, IdeaBlock, semantic distillation, probability mass). #### 🧩 Kinesthetic learners - Present: an implied hands-on path ("try it yourself," build-it-yourself instructions). - Improve: a runnable notebook comparing chunk vs claim retrieval on a sample corpus. #### 🧠 Logical learners - Present: clear cause→effect chain (wrong unit → fragmentation/version-collision/no-governance → downstream patching fails) and numeric backing. - Improve: a decision tree for when claim-unit embedding pays off; explicit assumptions behind each metric. #### 🧑‍🤝‍🧑 Social learners - Present: thread format invites replies/reshares. - Improve: discussion prompts for RAG practitioner groups; a shared benchmark to debate. #### 🧘‍♀️ Solitary learners - Present: self-contained argument readable in one sitting. - Improve: reflection prompts ("what's the wrong unit in *my* pipeline?"). #### 🌿 Naturalistic learners - Present: "retrieval surface" and "distillation layer grows like a CDN" use ecosystem/growth metaphors. - Improve: tie corpus minimization to compute/energy efficiency. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: plain-text thread; linear reading order works with assistive tech. - Improve: when republished, use real headings/landmarks and mark up the numeric comparisons as a table. #### Keyboard navigation - Present: X web client is broadly keyboard-operable. - Improve: ensure any embedded demo/repo links have visible focus and labels. #### Contrast and readability - Present: X default theme generally meets contrast norms. - Improve: verify 4.5:1 on link colors and any code styling. #### Text resizing and reflow - Present: thread text reflows responsively. - Improve: confirm no clipping of long numeric strings at 200% zoom. #### Media and captions - Present: no media — text-only, so no caption gap. - Improve: if a diagram/video is added later, provide alt text and captions. #### Forms and interactions - Present: standard reply/like controls. - Improve: ensure reshare/CTA controls are labeled for screen readers. #### Standards reference - Maps to WCAG 2.2 AA: 1.3.1 Info & Relationships (numbers should be a marked-up table), 1.4.3 Contrast, 2.1.1 Keyboard, 1.4.10 Reflow, 2.4.6 Headings/labels, 1.1.1 Non-text Content (for any future diagram). ### 🌍 DEIB Assessment #### Cultural breadth - Present: technical content is broadly culture-neutral; enterprise tooling examples (SharePoint, Confluence) skew Western/large-org. - Improve: examples beyond Western enterprise stacks; multilingual corpus considerations for embedding. #### Inclusive language - Present: neutral, jargon-heavy but mostly defined. - Improve: plain-language summary for non-specialists; expand acronyms on first use. #### Neurodiversity support - Present: short sentences and consistent structure aid scanning. - Improve: more signposting/subheadings and chunked summaries for long thread segments. #### Representation - Present: single author voice; no diversity dimension in the technical content. - Improve: cite a range of practitioners and independent benchmarks, not one vendor. #### Psychological safety - Present: confident but not hostile; critiques "almost no one examines" as observation, not blame. - Improve: acknowledge teams for whom chunking is adequate; avoid "you're doing it wrong" shaming framing. ### ✅ Logical Validity #### Strong reasoning - Causal (unit → failures): well-mechanized — a token-boundary splitter producing idea-agnostic containers cleanly explains fragmentation, version collision, and missing governance. Location: "Why the Chunk Is a Bad Unit." - Deductive (geometry): if near-duplicates create competing vectors, then collapsing them concentrates the signal — internally coherent. Location: "The counterintuitive finding." - Analogical: the CDN-layer comparison and "retrieval surface not a hard drive" are apt and clarifying. Location: "The Underlying Principle." - To strengthen: state the corpus/domain conditions under which each mechanism dominates. #### Fallacies - **Unsourced statistics / appeal to (vendor) authority** — every headline number is from one vendor's internal, unreproduced benchmark. Quote: "In Blockify's internal benchmark across 17 documents and 298 pages, the average cosine distance ... was 0.1585 ... versus 0.3624" and "Distilled dataset outperformed undistilled by 13.55%." Location: "This has a measurable consequence on vector geometry" and "The counterintuitive finding." Weakness: marketing-style metrics (40x, 3x, 2.3x) presented as general facts but tied to a 17-doc sample and a product the author promotes. Fix: label them as vendor-internal, single-corpus results; demand independent reproduction before generalizing. - **Hasty generalization** — "Every RAG pipeline starts with the same assumption" and "that assumption is almost never examined." Location: opening. Weakness: universal claims with no measurement of practitioner behavior. Fix: soften to "many pipelines" or cite survey evidence. - **Suppressed/loaded framing (advertising)** — the thread is a Blockify promotion ("Or you can use something purpose-built for it like Blockify"; "It's open-source! Try it yourself here→"). Location: "The Underlying Principle" and close. Weakness: conclusion conveniently routes to the author's product. Fix: separate the architectural argument from the product pitch; disclose commercial interest prominently. - **False dilemma (mild)** — "The fix is not a better retrieval algorithm. It's a better unit." Location: "The Underlying Principle." Weakness: presents unit-fixing and retrieval-tuning as either/or when they can be complementary. Fix: frame as "fix the unit *first*," not instead. #### Tone of voice - Confident, contrarian, didactic ("You're doing RAG wrong"); engineer-explainer register with vivid metaphors; closes in marketing/CTA mode. Authoritative but commercially motivated. ### 🛡️ DARVO Analysis - Deny: Not applicable — no accusation is being deflected; the thread asserts a position rather than defending against one. - Attack: None directed at people; it critiques the "chunk assumption" and downstream patching, not individuals or accusers. - Reverse victim/offender: None. - Overall: DARVO is largely not applicable to this source. It's a persuasive technical/marketing argument, not a defensive or accusatory exchange; the only rhetorical tension is the product-promotion framing, which is disclosed rather than concealed. ## 🎯 Conclusion - **Bottom line.** The thread's durable idea is that RAG quality is decided upstream by the *unit of knowledge* you embed: swap idea-agnostic text chunks for atomic question-answer packets carrying governance metadata, deduplicate to canonical claims, and the retrieval surface sharpens — often with a smaller corpus. The argument is coherent and worth acting on; the specific numbers are single-vendor and need independent verification. - **Next steps for readers.** (1) Audit your pipeline's embedding unit before touching the reranker. (2) Prototype claim-unit embedding on a slice of your corpus and measure recall@k yourself. (3) Test deduplication at 80–85% similarity and check whether accuracy rises as the corpus shrinks. (4) Treat the 40x/3x/2.3x figures as hypotheses, not benchmarks, until reproduced on a public dataset. ## 🔄 Refactor Appendix — You're doing RAG wrong > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults applied. Resonance filter on. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] The text chunk is the wrong unit of knowledge to embed > [!quote] ID:rw_pending > "Every RAG pipeline starts with the same assumption: a chunk of text is the right unit of knowledge to embed. That assumption is almost never examined." **Context & use**: - Opening thesis; the chunk is "a structurally neutral container" with no idea boundary, version, or access state. - Reframes retrieval failure as an upstream data-modeling problem, not a search-tuning one. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H2] Embed a question-answer packet, not a prose window > [!quote] ID:rw_pending > "When your index stores answers to questions, the match becomes structural, not just semantic." **Context & use**: - The IdeaBlock: one question, one validated answer, typed governance fields on one object. - User queries are already questions, so question→answer matching beats hoping the right paragraph floats up. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H3] Deduplicating to canonical claims raises accuracy while shrinking the corpus > [!quote] ID:rw_pending > "fifteen near-duplicates of the same paragraph create fifteen competing vectors in the same region of embedding space. Retrieval distributes probability mass across all of them" **Context & use**: - 2,042 → 1,200 blocks; 88,877 → 44,537 words; +13.55% vector accuracy (Blockify internal — unsourced, flag as vendor claim). - "Your vector index isn't a hard drive you want to fill. It's a retrieval surface, and redundancy degrades it." **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Retrieval quality is decided by the unit of knowledge, not the retrieval algorithm **Claim** (one sentence, Courtney's voice): The accuracy ceiling of a retrieval system is set upstream by how atomic and governance-bearing each embedded unit is, so fixing the knowledge unit yields larger gains than tuning the retriever. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for redundant, versioned enterprise corpora where chunks fragment ideas and collide across versions. Weaker for low-redundancy or inherently relational/multi-hop knowledge that resists atomization into single question-answer pairs. Note: supporting metrics are single-vendor and unreproduced. **Links**: - [[Concentration Beats Coverage Under Retrieval]] — because extends (fewer, canonical units beat broad redundant coverage at retrieval time) - [[Single source of truth]] — because applies-in (one canonical record propagates updates everywhere) - [[SaaS vendor lock-in]] — because contrasts on data control vs governance-in-data <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Independently reproduce the chunk-vs-claim retrieval benchmark on a public corpus before trusting the 40x/3x/2.3x figures — https://twitter.com/akshay_pachaar/status/2052743644411765230 #fleeting #inbox - [F2] Open question: does "one question, one answer" atomization lose multi-hop/relational knowledge that chunks preserve? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Link this thread's claim-unit thesis into [[Concentration Beats Coverage Under Retrieval]] as a fresh evidence/extension note — #things - [ ] Prototype claim-unit vs chunk retrieval on a sample corpus and measure recall@k myself — #things <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Tweets/You're Doing RAG Wrong.md|You're Doing RAG Wrong by Akshay 🚀]] ## Highlights - Every RAG pipeline starts with the same assumption: a chunk of text is the right unit of knowledge to embed. ([View Highlight](https://read.readwise.io/read/01kvnk0f68tceyhgazrhm8txca)) - Note: H1 — the unexamined assumption at the root of most retrieval failures: a text chunk is the wrong unit of knowledge to embed. - Tags: atom/literature/h1, rag, retrieval - Your queries are already questions. When your index stores answers to questions, the match becomes structural, not just semantic. ([View Highlight](https://read.readwise.io/read/01kvnk0h1jj4frdwys3zmdpaq5)) - Note: H2 — the fix: embed question→answer packets so retrieval matches structurally (question-to-question), not just on prose semantics. - Tags: atom/literature/h2, rag - The reason redundant copies hurt rather than help: fifteen near-duplicates of the same paragraph create fifteen competing vectors in the same region of embedding space. ([View Highlight](https://read.readwise.io/read/01kvnk0m2s79ysg4cbgs5wkpp4)) - Note: H3 + Permanent: near-duplicate chunks split probability mass across competing vectors — the same "concentration beats coverage under retrieval" law, now at the RAG-chunking layer. - Tags: retrieval, atom/zettel/z1, atom/literature/h3