Sub-system
A model's parameters are fixed at training time and contain no knowledge of your documents or of anything that happened since. Retrieval-augmented generation solves that by searching a corpus at request time and placing the relevant passages in the prompt — which changes the failure mode from confident invention to a citable answer.
In one sentence
Retrieval-augmented generation is a pattern in which a system searches an external corpus for passages relevant to a query and includes them in the model's prompt, so the answer is grounded in retrieved text rather than in memorised parameters.
The pattern is straightforward: embed and index a corpus, retrieve candidates for a query, optionally re-rank them, place the best in the prompt with an instruction to answer from them, and return the answer with its sources. Its value is less about capability than about accountability — an answer with the passage it came from can be checked.
It also solves a governance problem that fine-tuning does not. Permissions can be enforced at retrieval, so a user only ever sees passages they are allowed to see, and a document removed from the index stops influencing answers immediately. Neither is true of knowledge baked into weights.
Retrieval, not generation. If the right passage is not in the prompt, no model can produce a grounded answer from it. Most production improvements come from better chunking, hybrid keyword-plus-vector retrieval, and a re-ranking pass over the candidates — not from a larger language model.
They address different things. Fine-tuning teaches format, tone and task behaviour; retrieval supplies facts. Facts baked into weights cannot be updated without retraining, cannot be permission-scoped and cannot be cited. Most working systems fine-tune for behaviour and retrieve for knowledge.
A large context window makes it possible to paste a great deal of material into a prompt, but doing so costs money and latency proportional to the amount, and models still attend unevenly across very long inputs. Retrieving ten relevant passages is generally cheaper and more accurate than supplying a thousand and hoping.
Technology dependencies are solved by engineering; supply dependencies are solved by building something, which takes years.
The retrieval half of the pattern; its quality sets the ceiling on the whole system.
Embeddings and vector searchGrounding on internal documents is only deployable if the retrieval layer enforces who may see what.
Retrieved passages inflate prompts; caching shared prefixes is what keeps the pattern affordable at volume.
Context and cachingGrounding depends on the model actually using the supplied passages and saying so when they do not contain the answer. A base model that has not been post-trained does neither reliably.
Post-trainingSource material has to be parsed, split and kept current before anything can be retrieved from it. Most failures blamed on the model are a chunking or freshness problem in this stage.
Data processing frameworksWhat each company supplies at this step, and — where a public figure exists — its share of this specific market — with what that share measures, the period it covers and who published it. Some rows also show the company’s own reported revenue for the segment covering this step, which is a different thing: it says how much this business matters to that company, not how much of the market it holds. Not a ranking and not a recommendation.
Supplies the search engine most retrieval layers were built on, now with vector support.
Supplies vector search inside the operational database, which avoids a second system.
Supplies a managed vector database built for this workload.
Supplies Azure AI Search and the orchestration used in most enterprise deployments.
Supplies retrieval over data already governed in the warehouse.
Supplies an open-source vector database used for self-hosted retrieval.
Sells the grounding and retrieval layer beside its models, so the citation comes back with the answer.
Operates the managed knowledge-base and search services most enterprise deployments assemble this from.
Supplies the reranking models that decide which retrieved passages actually reach the prompt.
Supplies the orchestration most teams write the first version of this in.
Sells the finished thing — retrieval across a company's own systems — rather than the parts to build it.
Supplies retrieval over data already under the customer's governance, rather than copied into a second store.
Whether retrieval quality tooling — chunking, re-ranking, evaluation — consolidates into standard components.
Whether agentic systems that search iteratively displace single-shot retrieval.
Whether falling long-context cost changes the balance between retrieving little and supplying much.
Each page explains one technology in plain language, states what it depends on, and names companies by what they supply at that step. Company roles are described qualitatively and deliberately carry no market shares, revenue figures or rankings — those change faster than an explainer can, and a stale number is worse than none. Ticker links point at company pages on this site and are provided for reference only.
Nothing here is investment advice, a recommendation, or a forecast. A company named on a page about a technology is not thereby a good investment, and the chokepoints described are structural facts about supply chains rather than predictions about prices. Technology moves; where a page describes something as unresolved or in development, that was true when it was written.
Plutux no es un asesor de inversiones. Los datos de mercado y el análisis generado por IA son solo informativos y educativos, no asesoramiento de inversión. Aviso legal