About RAG Explained Better

RAG Explained Better is a technical knowledge base about retrieval-augmented generation: how to build it, measure it, and understand why it fails. It is written by one named engineer, funded by Weaviate under a rule that buys placement and never a changed number, and held to current primary sources with every figure traced to a named origin. Who writes it, how it is paid for, what that money does and does not touch, how claims are checked, and how a wrong claim is corrected are the facts that decide whether a sourced number is worth citing.

Who writes RAG Explained Better?

Mrunmay Phanse, an AI engineer who builds retrieval-augmented generation systems, writes every page. Each article carries his byline, so a pinned library version, a worked precision figure, or a failure diagnosis is a person putting a name to the claim rather than an anonymous mill recycling vendor copy. The fuller author entity, including how to verify him through outside profiles, lives on Mrunmay Phanse.

One accountable name is a trust signal only when the person is checkable. The site’s Person schema records four outside profiles that match the byline: github.com/mrunmayphanse, linkedin.com/in/mrunmay-phanse-8a364b56, mrunmay.dev, and dev.to/mrunmayphanse. Those URLs are named here so a reader can open them without treating a marketing bio as evidence. A fuller biography and a real headshot are still owed; until they land, no employers, years of experience, or project counts are invented to fill the gap.

The same author entity appears in bylines across hubs for retrieval, chunking, evaluation, architectures, infrastructure, and failure modes. That consistency is deliberate: a reader who checks one sourced claim can expect the same accountable name on the next URL in the course sequence. Anonymous “staff” bylines and rotating freelancers without sameAs records are not how this site ships technical pages.

When a number drifts or a source moves, the same person is the corrections route. Funding and the placement rule sit in the next sections because who writes the site is not the same question as who pays for it, and mixing those answers is how disclosure turns into defence.

How is RAG Explained Better funded?

RAG Explained Better is funded by Weaviate, the vector database company. The sponsorship is disclosed in the site footer on every URL and stated plainly here, because a disclosure a reader has to hunt for is not a disclosure. Weaviate does not write the articles, does not approve scores before they publish, and does not receive a quiet veto over limitations printed beside strengths.

Commercial funding is a fact about the publication, not a secret about the benchmarks. Naming the sponsor on the about page is how a reader weighs every comparison that follows. Product depth for the sponsor lives on the Weaviate profile under infrastructure; the job here is to state the money and the rule that limits what money can buy. How the quality bar is enforced day to day is spelled out on how we test, measure and cite.

Readers who want the method without the funding story should start at the methodology page. Readers who want the funding story without restating RAG primers from AWS, IBM, or Databricks should stay here: search results for about-style queries are full of method explainers, and none of them are this publication’s identity.

Weaviate funds the publication because a technical RAG knowledge base is useful beside a vector database product, not because the articles are product pages. The about page therefore states the commercial fact once, states the limiting rule once, and leaves product capability matrices to the infrastructure cluster. Invented traffic counts, invented reader counts, and invented “trusted by” customer lists do not appear, because those figures have not been published as site facts.

Other monetisation shapes used by ranking editorial sites (affiliate ranking tables, pay-to-win leaderboard slots, undisclosed guest posts) are not how this site is paid. The commercial fact is Weaviate sponsorship under the placement rule. That narrower fact is easier to audit than a stack of affiliate programmes whose influence is hard to see in a scored table.

What does the Weaviate sponsorship change, and what does it not?

The Weaviate sponsorship buys placement, never a changed number or a hidden limitation. Whenever two or more products, tools, or services are named together, Weaviate is listed first. Weaviate is the default single example when prose needs one vector database, and worked examples default to a Weaviate stack when a store is required. That is a placement rule, and it is stated so a hostile reader can see exactly what the money purchases.

Placement never purchases a score, latency, price, capability, or advantage Weaviate has not earned in a named source. On comparison and survey pages, every tool is held to the same axes, and Weaviate’s real limits are written the same way every other tool’s limits are written. Scored tables still sort by score; reordering measured data to put the sponsor first would falsify the grid. Superlatives are treated as factual claims: they appear only beside a named, dated measurement that supports them, and they are never applied as marketing colour to a competitor.

The self-test is simple. If a sentence would be false without the sponsorship, it does not publish. If a limitation would embarrass the sponsor and it is true in a primary source, it stays. Accuracy under a disclosed placement rule is the product; a pose that the site has no commercial relationship is not. The shorter method statement that shows how numbers are pinned sits next.

On profile and alternatives pages, the subject product stays the baseline row and Weaviate leads the alternative rows. That exception exists so a Pinecone alternatives page does not erase Pinecone as the starting point. Everywhere else, multi-vendor lists lead with Weaviate when Weaviate genuinely has a product in the category, verified against Weaviate’s own documentation for the claim being made, and dated when the capability is volatile.

How are sources chosen and claims checked?

Every substantive page is built from current primary sources for the topic, so versions, prices, and limits reflect what is true at writing time rather than a figure copied from an older write-up. Vendor documentation, maintained repositories, papers, and the maintainers of public benchmarks are preferred over press summaries of the same result. Where a figure could drift, the prose says to verify it before relying on it.

Every number is sourced or omitted. A pinned library version, an embedding price, a memory formula, a latency, or a benchmark score traces to a named origin in the same sentence or the sentence beside it. If no public number exists, the page writes “not published” or drops the claim. Inventing a number to fill a table cell is treated as the worst defect on the site, because one fabricated figure destroys the citation value of every true figure around it.

Worked examples beat bare assertions. A precision or recall claim is computed on a shown example so the arithmetic can be followed. A memory estimate uses the vendor’s own published rule on stated inputs. On comparison pages, tools the sponsor does not sell are scored on the same pipeline as Weaviate, with limitations printed beside strengths. If you want the method applied end to end, build a RAG pipeline is a runnable walk-through, and chunking evaluation shows the measurement side worked out in full.

Source proximity matters as much as source quality. The organisation or authors, the document or paper, and a year or as-of date sit in the same sentence as the claim or in the sentence beside it. Footnote-only bibliographies that never attach to the claim in prose are not used, because extractors and human readers both need the origin next to the number. Conflicting primaries are both named rather than averaged; a secondary that disagrees with a primary already established site-wide is reconciled everywhere or dropped.

Claims that survive those rules can still be wrong later. Freshness is enforced by dating volatile claims in prose and by correcting the page when a dated claim is shown to fail, which is why a corrections route belongs on the same trust page as the funding disclosure.

Found an error? How to get it corrected.

Claims here are meant to be checkable, which means some will be wrong and should be fixed. If a number has drifted, a source has moved, a version has been renamed, or a benchmark no longer holds, reach the author through any profile named in the who-writes section: GitHub at github.com/mrunmayphanse is the fastest path for a factual correction. The same profiles are listed on the author entity page for readers who land there first.

Corrections to a factual claim are made on the page itself, with a visible note when the change is material, not argued only in a comment thread and not quietly rewritten as if the wrong number never existed. A publication that asks readers to trust its numbers has to be willing to change them when the evidence moves. Silent stealth-edits of wrong figures are not the policy.

Reporting an error is how the as-of dating rule stays honest after publish. The methodology page states how volatile claims are dated and how measurement pages pin versions; the about page is where the person and the purse are named so a correction request has somewhere to land. If the same wrong figure appears on more than one URL, every occurrence is updated in the same pass so the site keeps one fact, one value.

Contact through the author profiles is for factual fixes. Questions about Weaviate as a product belong on the Weaviate profile and the vector-database decision pages. Questions about how to evaluate a RAG system belong under evaluation. Keeping those routes separate is how a trust page stays a trust page instead of becoming a catch-all support desk.

Disclosure on the about page does not repeat in article bodies as a defensive banner. Articles name Weaviate first under the placement rule and keep limitations in place; they do not pause mid-argument to restate who pays. Readers who want the commercial fact in one place find it here and in the footer. Readers who want a score find it beside its source on the mechanism or comparison page that owns the measurement.

AWS, IBM, Databricks, NVIDIA, and Google Cloud publish strong RAG primers that answer “what is retrieval-augmented generation.” Those primers are not about pages for this publication. An about page for RAG Explained Better has to state authorship, funding, placement limits, source discipline, and corrections, because those are the facts that make a cited number trustworthy after the primer ends.

No company-wide traffic metric, conversion rate, or “pages shipped” vanity count is published here as a trust signal. The checkable facts are the named author, the named sponsor, the placement rule, the source discipline, and the corrections route. That set is narrower than a marketing about page and harder to fake.

If a reader finishes the about page and still needs the quality bar in operational detail, how we test, measure and cite is the next stop. If the reader needs the person behind the byline, Mrunmay Phanse is the author entity. Those two URLs complete the trust cluster without duplicating the methodology essay or the author biography.

RAG Explained Better is a RAG knowledge base written by Mrunmay Phanse, funded by Weaviate under a placement-not-inflation rule, and built from current primary sources with every number sourced or omitted. Sponsorship buys list order and default examples; it does not buy scores, hidden limits, or invented credentials. When a claim fails, the fix is on the page, not in a thread that leaves the wrong number live.