1. RAG and context windows (the short version)

• RAG is "retrieve, then hand over fragments": The original paper by Lewis et al. combined a pre-trained generation model (parametric memory) with a vector index of Wikipedia (non-parametric memory)Sourced[Ref. 1]. Keeping knowledge outside the model makes it easier to cite sources and to swap knowledge (commentary).
• Declared context windows are large, but effective performance is a different matter: Anthropic's official documentation says that several models have a 1M-token window, and also states that as token count grows, accuracy and recall degrade, a phenomenon called "context rot"Sourced[Ref. 23]. The RULER paper reports that among 17 models claiming 32K or more, only half kept satisfactory performance at 32K [Ref. 15].
• A long context costs memory: From published configurations, the KV cache of Llama 3.1 8B is 16 GiB at 128K tokens and 40 GiB for 70BOur calculation (Chapter 6).

2. The structure of RAG — the original papers and the big picture

(1) The structure the original papers showed

Lewis and colleagues presented RAG models that use a pre-trained seq2seq model as parametric memory and a dense vector index of Wikipedia as non-parametric memory. They split Wikipedia articles into disjoint 100-word chunks, giving about 21 million documents, computed an embedding for each, and built an approximate-search index (HNSW) with FaissSourced[Ref. 1]. DPR by Karpukhin and colleagues, from the same period, likewise used 21,015,324 passages of 100 words from Wikipedia as retrieval units, made 768-dimensional vectors with BERT (base), and indexed them with Faiss [Ref. 2]. The motivation of RAG, to make sources easier to show and knowledge easier to update with external knowledge, is stated at the start of the original paper [Ref. 1]. REALM built in, from the pre-training stage, a latent retriever that fetches and attends to documents from a large corpus such as Wikipedia, aiming to hold knowledge in a more modular and interpretable form than implicitly in parameters [Ref. 3].

(2) The big picture: preprocessing and query time

RAG can be organized into two stages: preprocessing, which makes documents searchable, and query time, which retrieves and builds a context for each question. Anthropic's explanation describes the standard flow: split the knowledge base into pieces of at most a few hundred tokens, turn them into vectors with an embedding model, and at run time fetch from the vector database the pieces closest to the question and add them to the prompt [Ref. 25].

View original SVG, values and source annotations

The experience report by Barnett and colleagues presents seven failure points to consider when designing a RAG system, from three case studies in research, education and biomedicine, and gives as its main takeaways that validation of a RAG system is only feasible during operation and that its robustness evolves rather than being designed in at the startSourced[Ref. 14]. In other words, it is realistic to build with the assumption that you keep measuring in operation instead of evaluating once at introduction (commentary).

3. Embeddings and vector search

(1) Embeddings: turning text into numbers that can be compared by closeness

Sentence-BERT reports that finding the most similar pair among 10,000 sentences takes about 50 million inference computations (about 65 hours) with BERT's pair input, and that making an embedding per sentence and comparing them by cosine similarity cut this to about 5 secondsSourced[Ref. 6]. This idea of "embed documents beforehand, and at query time embed only the question and look for what is close" is the basis of RAG retrieval (commentary).

(2) Approximate nearest-neighbor search: finding what is close without comparing everything

With millions or tens of millions of documents, computing similarity between the question and every item becomes heavy. HNSW (hierarchical navigable small world graphs) was proposed as an approximate nearest-neighbor method that searches multi-layer graphs and achieves logarithmic scaling of complexity [Ref. 7]. Faiss is a library for vector similarity search (indexing, searching, clustering, compression), and its paper describes the trade-off space of accuracy, speed and memory and its design principles [Ref. 8]. ScaNN's anisotropic vector quantization is also a way to speed up large-scale search [Ref. 9]Sourced. Because it is approximate, it can miss the truly closest item, and accuracy and speed change with settings (commentary).

(3) Combining with lexical search (BM25)

Embeddings capture closeness of meaning but can miss exact phrase matches. Anthropic's explanation says that BM25 is a ranking function based on lexical matching that is especially effective for queries with unique identifiers or technical terms; for example, an exact match such as the error code "TS-999" can be hard for embeddings to find [Ref. 25]. BEIR evaluated 10 retrieval systems on 18 public datasets and reported that BM25 is a robust baseline, that re-ranking and late-interaction methods achieve the best zero-shot performance on average but at high computational cost, and that dense and sparse retrieval are computationally efficient but often underperform the othersSourced[Ref. 10]. MTEB evaluated 33 models on 8 tasks, 58 datasets and 112 languages and reported that no single embedding method dominates across all tasks [Ref. 11].

(4) Memory for vectors: our calculation

The size of a vector index is roughly "number of chunks × dimensions × bytes per element". We calculated it for DPR's scale (21,015,324 items, 768 dimensions) and for one million chunks with different dimensions.

Our calculation (GB = 10⁹ bytes). The numbers of chunks and dimensions are illustrative assumptions (DPR's count and 768 dimensions are from the paper [Ref. 2]). The extra memory of indexes such as HNSW, metadata and storage of the text are not included.

In other words, at the scale of in-house documents, the vectors themselves can fit in the main memory of a single server. Retrieval accuracy and speed are decided not by the memory size but by the quality of the embeddings, the index settings and the chunking (commentary). Also, embeddings are not anonymization. Morris and colleagues report that a method that reconstructs the original text from embeddings could exactly recover 92% of 32-token inputs and could also recover personal information such as full names from a dataset of clinical notesSourced[Ref. 16]. Embeddings of confidential documents should also be handled as confidential information (commentary).

4. Chunking — the problem of cutting tables, conditions and units

(1) The choice of granularity changes retrieval accuracy

Dense X Retrieval by Chen and colleagues showed that the choice of retrieval unit (document, passage, sentence) strongly affects retrieval and downstream performance. Indexing by a fine-grained unit called a "proposition", an atomic factoid expressed in a self-contained form, outperformed passage-level units in retrieval and also improved downstream question answering under a given computation budgetSourced[Ref. 13]. The late chunking of Günther and colleagues uses a long-context embedding model to embed all tokens of the long text first and applies chunking just before pooling, so that chunk embeddings capture the surrounding context [Ref. 12].

(2) Adding context to a fragment: Contextual Retrieval

A fragment on its own can lose what it is about. In its explanation of 19 September 2024, Anthropic presented "Contextual Retrieval", which prepends a chunk-specific explanation generated from the whole document to each chunk before building the embeddings and the BM25 index, and said it reduced failed retrievals by 49%, and by 67% when combined with rerankingSourced[Ref. 25]. This is the developer's own experiment, and we have not confirmed an independent replication. The same explanation also says that if the knowledge base is smaller than about 200,000 tokens (about 500 pages), you can include all of it in the prompt without RAG (a statement as of 2024) [Ref. 25].

(3) Chunk size and count: our calculation

With a document length of T tokens, a chunk size s and an overlap o, the number of chunks is roughly ⌈(T−o)/(s−o)⌉. For a 100,000-token document (assumed to be about 200 A4 pages), split with an overlap of 10% of the chunk size, we calculated the number of chunks and the tokens when the top 5 are put into the context.

Our calculation (number of chunks = ⌈(T−o)/(s−o)⌉, with T = 100,000 assumed). "Context" counts only the tokens of the chunks themselves, not the question, instructions or answer.

Smaller chunks are focused on one topic and easier to hit in retrieval, but they cut context and increase the number of chunks. Larger chunks keep context but lower retrieval accuracy and increase the tokens handed to the LLM (commentary). The best size differs with the kind of document (reports, standards, test reports heavy in tables), and there is no general answer.

5. Long context — declared values and effective performance

(1) Declared values: how much is said to "fit"

Anthropic's official documentation (checked 15 October 2026) states that several models, including Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5, have a 1M-token context window and that a single request can generate up to 128k output tokens. The other models have 200k tokens [Ref. 23]. Google's Gemini API documentation says that for Gemini 4 models, input, thinking and output tokens share a single context window (1,048,576 tokens) [Ref. 24]. The Llama 3 paper gives the context window of its largest model as up to 128K tokens [Ref. 26], and the gpt-oss model card says it extended the dense layers to 131,072 tokens with YaRN [Ref. 30]Sourced. These are declared upper limits on input, not a guarantee that the model can use inputs of that length accurately.

(2) Effective performance: what happens as the input gets longer

All Sourced (papers and official pages; checked 15 October 2026). The right-hand column is our commentary.

6. Memory and compute of the KV cache (our calculation)

(1) What the KV cache is and how to calculate it

When an LLM generates text one token at a time, it does not recompute the keys (K) and values (V) used in the attention of all past tokens every time; it stores them in memory and reuses them. This is the KV cache, which, the KIVI paper explains, becomes a new bottleneck in memory use and speed with larger batches and longer contexts [Ref. 34]. The size of the KV cache per token can be estimated with the following formula (our formula).

MQA (Shazeer) [Ref. 32] and GQA (Ainslie et al.) [Ref. 31], in which several queries share one set of KV, are ways to reduce the "KV heads" term in this formula. Llama 3 uses GQA with 8 KV heads and explains that the aim was to speed up inference and shrink the KV cache [Ref. 26]. MLA (multi-head latent attention) in DeepSeek-V2 stores only (d_c + d_R^h) × layers elements per token, and is reported to have reduced the KV cache by 93.3% compared with DeepSeek 67BSourced[Ref. 29].

(2) Calculation by model

From published configurations we calculated the KV cache in bf16 (2 bytes per element) for a batch of 1 and a single sequence. The configurations come from the table in the Llama 3 paper [Ref. 26] for Llama 3.1, and from the official config.json for DeepSeek-V3 and gpt-oss-120b [Ref. 27, 28].

Our calculation (KiB = 1,024 bytes, GiB = 1,024³ bytes). The configurations are Sourced (the table in the Llama 3 paper, the official config.json of DeepSeek-V3 and gpt-oss, and the description of the attention pattern in the gpt-oss model card). The 1M-token column is an arithmetic extrapolation; the declared window of each model is around 128K (Llama 3.1: 128K; DeepSeek-V3 config: 163,840; gpt-oss: 131,072). For gpt-oss the windowed layers' share (about 4.5 MiB) is added. Weights, activations and implementation headroom are not included.

At the same 128K tokens, Llama 3.1 8B needs 16 GiB, 70B needs 40 GiB, gpt-oss-120b (half of its layers windowed) 4.5 GiB and DeepSeek-V3 (MLA) 8.6 GiB, so it differs by several times depending on the design of the model. The KV cache also grows in proportion to the number of sequences processed at once (the batch): for Llama 3.1 8B processing eight 128K sequences at once, the KV alone is 128 GiB (our calculation).

Countermeasures to this problem can also be confirmed in primary sources. PagedAttention (vLLM) prevents KV-cache memory from being wasted by fragmentation and duplication through paging like an operating system's virtual memory, achieving near-zero waste and, the authors report, 2 to 4 times the throughput at the same latency [Ref. 33]. KIVI quantizes the KV cache to 2 bits and, while keeping almost the same quality on Llama, Falcon and Mistral, reduced peak memory including weights by 2.6 times and allowed up to 4 times larger batches, the authors report [Ref. 34]Sourced. These are the authors' experiments, and the effect on accuracy is conditional.

(3) What the compute is made of, and decode speed: our calculation

As the context gets longer, not only memory but also the content of the compute changes. In prefill, which processes the input in one pass, the attention compute grows with the square of the context length L, while the compute of the linear layers (weight-matrix products) grows with L. A rough estimate for Llama 3.1 8B (about 8 billion parameters, 32 layers, attention dimension 4,096), allowing for the causal mask, puts the point where attention compute exceeds the linear layers at about 61,000 tokens. At 128K tokens, the attention compute is about 2.1 times that of the linear layersOur calculation.

In decode, which produces output one token at a time, each token reads the weights and the KV cache so far from memory. Assuming a memory bandwidth of 3 TB/s, the lower-bound speed from reading the weights alone (8 billion × 2 bytes) is about 188 tokens per second; about 176 with an 8K context; and about 90 tokens per second with a 128K context, where an additional 16 GiB of KV cache must be readOur calculation (an upper bound for a single sequence; the real figure changes with parallelism, quantization and cache layout).

7. RAG or long context?

Li and colleagues compared RAG with long-context (LC) LLMs on three recent models and several public datasets. They found that, when sufficiently resourced, LC consistently outperforms RAG in average performance, while RAG retains the advantage of a far lower cost. They proposed Self-Route, which routes each query to RAG or LC by the model's self-reflection, and say it greatly reduces computation cost while keeping performance comparable to LCSourced[Ref. 21]. Self-RAG retrieves only when needed and checks the retrieved passages and its own generation with reflection tokens [Ref. 4].

This table is our commentary. The primary source for the relation between performance and cost is the paper by Li et al. [Ref. 21], and for the option when the knowledge base is small, Anthropic's explanation [Ref. 25].

Which is better depends on the volume of material, the frequency of updates, the need for sources, how access rights are managed and the budget, and there is no general answer. For a small knowledge base (Anthropic's explanation gives under about 200,000 tokens as an example), putting it all in is simple; for a large knowledge base or where access control is needed, RAG is realistic (commentary).

8. Using it on in-house documents and research data, and cautions

When RAG is used on in-house reports, test reports, standards and research data, access rights, security, sources, updates and reproducibility must be designed in as well as accuracy. We set out the points that can be confirmed in primary sources.

(1) Access rights and confidentiality

OWASP's Top 10 for LLM Applications (2025 edition), in LLM08 "Vector and Embedding Weaknesses", says that weaknesses in how RAG vectors and embeddings are generated, stored or retrieved can be exploited to inject harmful content, manipulate outputs or access sensitive information. Its examples include leakage of sensitive information through inadequate access controls and context leakage between users or tenants when several share one vector database. Its mitigations include fine-grained access control with permission-aware vector and embedding stores, logical and access partitioning of datasets, and keeping logs of retrieval activitySourced[Ref. 35]. As Chapter 3 noted, there is also research that reconstructs original text from embeddings [Ref. 16]. The basic rule is to apply permissions per user at the retrieval stage, and to treat embeddings and indexes like the confidential documents themselves (commentary).

(2) Instructions planted in documents, and poisoned documents

OWASP's LLM01 "Prompt Injection" describes indirect prompt injection, in which an LLM takes in input from external sources such as websites or files and instructions in that content unintentionally change the model's behavior, and its countermeasures include segregating and identifying external content [Ref. 36]. PoisonedRAG by Zou and colleagues showed that injecting malicious text into a knowledge database is a new attack surface; injecting five malicious texts per target question into a database of millions of texts gave about a 90% attack success rate, and the defenses evaluated were insufficientSourced[Ref. 22]. A first step is to manage the provenance of documents you ingest, and not to put documents from outside, or documents that anyone can write to, into the index on the same footing as trusted in-house documents (commentary). This article does not cover concrete attack procedures.

(3) Sources, grounding and hallucination

NIST AI 600-1 (Generative AI Profile, July 2024) lists among the risks specific to generative AI the production of confidently stated but erroneous or false content (confabulation, colloquially "hallucination") [Ref. 37]. One motivation of RAG is to show sources [Ref. 1], but even if retrieved fragments are handed over, the model can ignore or mix them up. OWASP lists three things to assess in responses, context relevance, groundedness and question/answer relevance (the RAG Triad) [Ref. 36]. Ragas proposes metrics, without human ground truth, for the ability of retrieval to find relevant and focused passages, the ability of the LLM to use them faithfully, and the quality of the generation [Ref. 5].

(4) Updates, versions and reproducibility

Barnett and colleagues state that the robustness of a RAG system evolves in operation rather than being designed in at the start [Ref. 14]. Because standards and in-house standards are revised, so that fragments of old versions do not mix into retrieval, you need to carry each document's version and validity period in the index metadata and to drop the old version when updating (commentary). The same question can also give different answers depending on the contents of the index, the retrieval settings and the model version, so for an answer used in an important decision, record the retrieval date, the index version, the model version and the fragments referred to.

Checklist before adoption (commentary)

• Target documents: which documents, for whom, for what decision. Are documents from outside mixed in?
• Access rights: can the user's permissions be applied at the retrieval stage? Is an index shared across departments or business partners?
• Splitting and parsing: are tables, figures, equations, chemical formulas and units intact? Did you look at the actual chunks for representative documents?
• Retrieval: does searching by part number or standard number bring the right document to the top (hybrid search with lexical search)? Did you measure how often the correct chunk is in the top k (recall@k)?
• Generation: do answers carry the source, page and conditions? Do they avoid answering with content that is not in the chunks (faithfulness to the grounds)?
• Evaluation: did you measure retrieval and generation separately with your own set of questions and answers? Did you vary the context length and the position of the needed information?
• Operation: is there a way to update documents and drop old versions, and to keep logs (questions, retrieval results, answers) and records (retrieval date, versions)?

9. Limits, and what could not be confirmed

(1) Freshness of long-context evaluations

The long-context evaluations in Chapter 5 (Lost in the Middle, RULER, NoLiMa) are results for the models of the time of each paper, and we did not check the effective performance of each company's latest models as of 15 October 2026. We also did not check whether a version newer than the one seen on the HELM Long Context page (v1.0.0, 29 September 2025) has appeared.

(2) Calculations such as the KV cache

The calculations in Chapter 6 are rough estimates derived from published configurations. Actual implementations change with KV-cache quantization, paging, prefix sharing and tensor parallelism. The memory bandwidth of 3 TB/s and single-sequence decoding are illustrative assumptions, not measurements of any product. The Llama 3.1 configuration comes from the table in the paper; we did not check the official config.json (it is gated).

(3) The developers' own experiments

The improvement from Contextual Retrieval (failures reduced by 49% and 67%) is Anthropic's own experiment, and we could not confirm an independent replication. The figures of PagedAttention, KIVI and DeepSeek-V2 are also reports by the authors of each paper.

(4) The text of standards, and standards specific to RAG

For ISO/IEC standards we checked only the title, publication date and scope (abstract), not the full text. We could not confirm an international standard that directly defines the performance of RAG or vector search. OWASP documents are community guidance, not standards.

(5) Effect on materials and research data

We could not confirm a primary source that measured the accuracy of applying RAG or long context to materials documents (test reports, standards, datasheets), or the effectiveness of this article's checklist and handling of tables. The materials-related statements in Chapters 4 and 8 are this article's commentary and inference.

10. How to read evaluations and standards

Evaluation of RAG and long context can be considered in four parts: retrieval quality (does the right chunk come out on top), generation quality (does it answer faithfully to the chunks), effective long-context performance (degradation with length and position) and resources (memory, latency, cost). We could not confirm an international standard that directly defines these, and standards and guidelines exist mainly as frameworks for risk management, data quality and testing. The table below lists what we could confirm, with a type for each row.

Standard numbers, titles and publication dates were checked on the official ISO, NIST and OWASP pages (Sourced; checked 15 October 2026). The essentials of benchmarks come from each original paper. The arrangement of the table and the "cautions in reading" column are Our calculation (our own organization).

Cautions in reading

• Benchmark values change with the settings and the evaluator. Retrieval benchmarks change with language, field and document length, and long-context benchmarks with the task and the position in the context. A developer's own experiment (such as Contextual Retrieval) is not an independent evaluation.
• Watch for saturation and contamination. As the needle test (NIAH) is near-perfect while RULER and NoLiMa show drops, an evaluation saturated on an easy metric does not reflect the difficulty of practice.
• Read standards and guidelines by whether they recommend or require, and whether they have legal force. NIST AI 600-1 and AI 100-1 are voluntary frameworks, OWASP is community guidance, an ISO/IEC TR is a report, and 42001 is a standard with requirements. None of them sets pass or fail for RAG "retrieval accuracy" or "effective context length".
• Distinguish declared values from measured values. A declared context window (such as 1M tokens) is not effective performance, and a calculated KV cache is not a measured memory use. Measure in your own environment.

11. Glossary

12. References (primary sources)

1. Lewis P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401 (2020; v4 April 2021) — arxiv.org/abs/2005.11401
2. Karpukhin V. et al. "Dense Passage Retrieval for Open-Domain Question Answering", arXiv:2004.04906 (2020; v3 September 2020) — arxiv.org/abs/2004.04906
3. Guu K. et al. "REALM: Retrieval-Augmented Language Model Pre-Training", arXiv:2002.08909 (February 2020) — arxiv.org/abs/2002.08909
4. Asai A. et al. "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection", arXiv:2310.11511 (October 2023) — arxiv.org/abs/2310.11511
5. Es S. et al. "Ragas: Automated Evaluation of Retrieval Augmented Generation", arXiv:2309.15217 (2023; v2 April 2025) — arxiv.org/abs/2309.15217
6. Reimers N., Gurevych I. "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks", arXiv:1908.10084 (August 2019) — arxiv.org/abs/1908.10084
7. Malkov Yu. A., Yashunin D. A. "Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs", arXiv:1603.09320 (2016; v4 August 2018) — arxiv.org/abs/1603.09320
8. Douze M. et al. "The Faiss library", arXiv:2401.08281 (2024; v4 October 2025) — arxiv.org/abs/2401.08281
9. Guo R. et al. "Accelerating Large-Scale Inference with Anisotropic Vector Quantization", arXiv:1908.10396 (2019; v5 December 2020; ScaNN) — arxiv.org/abs/1908.10396
10. Thakur N. et al. "BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models", arXiv:2104.08663 (2021; v4 October 2021) — arxiv.org/abs/2104.08663
11. Muennighoff N. et al. "MTEB: Massive Text Embedding Benchmark", arXiv:2210.07316 (2022; v3 March 2023) — arxiv.org/abs/2210.07316
12. Günther M. et al. "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models", arXiv:2409.04701 (2024; v3 July 2025) — arxiv.org/abs/2409.04701
13. Chen T. et al. "Dense X Retrieval: What Retrieval Granularity Should We Use?", arXiv:2312.06648 (2023; v3 October 2024) — arxiv.org/abs/2312.06648
14. Barnett S. et al. "Seven Failure Points When Engineering a Retrieval Augmented Generation System", arXiv:2401.05856 (January 2024) — arxiv.org/abs/2401.05856
15. Hsieh C.-P. et al. "RULER: What's the Real Context Size of Your Long-Context Language Models?", arXiv:2404.06654 (2024; v3 August 2024) — arxiv.org/abs/2404.06654
16. Morris J. X. et al. "Text Embeddings Reveal (Almost) As Much As Text", arXiv:2310.06816 (October 2023) — arxiv.org/abs/2310.06816
17. Liu N. F. et al. "Lost in the Middle: How Language Models Use Long Contexts", arXiv:2307.03172 (2023; v3 November 2023) — arxiv.org/abs/2307.03172
18. Modarressi A. et al. "NoLiMa: Long-Context Evaluation Beyond Literal Matching", arXiv:2502.05167 (2025; v3 July 2025) — arxiv.org/abs/2502.05167
19. Bai Y. et al. "LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding", arXiv:2308.14508 (2023; v2 June 2024) — arxiv.org/abs/2308.14508
20. Stanford CRFM "HELM Long Context" (leaderboard; the version seen on the page was v1.0.0, 29 September 2025; checked 15 October 2026) — crfm.stanford.edu/helm/long-context/latest/
21. Li Z. et al. "Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach", arXiv:2407.16833 (2024; v2 October 2024) — arxiv.org/abs/2407.16833
22. Zou W. et al. "PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models", arXiv:2402.07867 (2024; v3 August 2024) — arxiv.org/abs/2402.07867
23. Anthropic "Context windows" (Claude API documentation; checked 15 October 2026) — platform.claude.com/docs/en/build-with-claude/context-windows
24. Google "Gemini thinking" (Gemini API documentation; statement on the Gemini 4 context window and output limits; checked 15 October 2026) — ai.google.dev/gemini-api/docs/thinking
25. Anthropic "Introducing Contextual Retrieval" (19 September 2024) — www.anthropic.com/news/contextual-retrieval
26. Llama Team (Grattafiori A. et al.) "The Llama 3 Herd of Models", arXiv:2407.21783 (July 2024; v3 November 2024) — arxiv.org/abs/2407.21783
27. DeepSeek-AI "deepseek-ai/DeepSeek-V3" (config.json on the official Hugging Face model page; checked 15 October 2026) — huggingface.co/deepseek-ai/DeepSeek-V3/blob/main/config.json
28. OpenAI "openai/gpt-oss-120b" (config.json on the official Hugging Face model page; checked 15 October 2026) — huggingface.co/openai/gpt-oss-120b/blob/main/config.json
29. DeepSeek-AI "DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model", arXiv:2405.04434 (2024; v5 June 2024; MLA) — arxiv.org/abs/2405.04434
30. OpenAI "gpt-oss-120b & gpt-oss-20b Model Card", arXiv:2508.10925 (8 August 2025) — arxiv.org/abs/2508.10925
31. Ainslie J. et al. "GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints", arXiv:2305.13245 (2023; v3 December 2023) — arxiv.org/abs/2305.13245
32. Shazeer N. "Fast Transformer Decoding: One Write-Head is All You Need", arXiv:1911.02150 (November 2019; MQA) — arxiv.org/abs/1911.02150
33. Kwon W. et al. "Efficient Memory Management for Large Language Model Serving with PagedAttention", arXiv:2309.06180 (September 2023; vLLM) — arxiv.org/abs/2309.06180
34. Liu Z. et al. "KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache", arXiv:2402.02750 (2024; v2 July 2024) — arxiv.org/abs/2402.02750
35. OWASP "LLM08:2025 Vector and Embedding Weaknesses" (OWASP Top 10 for LLM Applications 2025; checked 15 October 2026) — genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
36. OWASP "LLM01:2025 Prompt Injection" (OWASP Top 10 for LLM Applications 2025; checked 15 October 2026) — genai.owasp.org/llmrisk/llm01-prompt-injection/
37. NIST "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", NIST AI 600-1 (July 2024), DOI 10.6028/NIST.AI.600-1 — doi.org/10.6028/NIST.AI.600-1
38. NIST "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", NIST AI 100-1 (January 2023), DOI 10.6028/NIST.AI.100-1 — doi.org/10.6028/NIST.AI.100-1
39. ISO/IEC "ISO/IEC TS 42119-2:2025 Artificial intelligence — Testing of AI — Part 2: Overview of testing AI systems" (November 2025) — www.iso.org/standard/84127.html
40. ISO/IEC "ISO/IEC 5259-2:2024 Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 2: Data quality measures" (November 2024) — www.iso.org/standard/81860.html
41. ISO/IEC "ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system" (December 2023) — www.iso.org/standard/81230.html
42. ISO/IEC "ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management" (February 2023) — www.iso.org/standard/77304.html
43. ISO/IEC "ISO/IEC TR 17903:2024 Information technology — Artificial intelligence — Overview of machine learning computing devices" (May 2024; technical report) — www.iso.org/standard/85078.html
44. ISO/IEC "ISO/IEC TR 20226:2025 Information technology — Artificial intelligence — Environmental sustainability aspects of AI systems" (July 2025; technical report) — www.iso.org/standard/86177.html

13. Claim-to-source audit

Last updated: 15 October 2026 (check date). Sources are limited to primary materials: original papers, developers' official documentation, config.json files and model cards, and the official OWASP, NIST and ISO pages. The full text of the standards is paid and was not checked. Specifications such as context length change quickly, and we do not guarantee the state after the check date. The effective long-context performance of the latest models of each company, an international standard defining the performance of RAG or vector search, the accuracy of RAG on materials documents, the effectiveness of the checklist, the official config.json of Llama 3.1, and any newer version of HELM Long Context could not be confirmed and are not stated. The calculations of the KV cache, vectors and chunks are rough estimates from published configurations and illustrative assumptions, and differ from actual implementations. Figs. 2 to 5 are vector drawings; Figs. 1 and 6 are AI-generated concepts (frames with no image placed). None of them shows the inside of a real product or data on a real material.