RAG · Indexing, Chunking, Retrieval, Reranking & Context Assembly

1. Introduction

1.1. Background

Retrieval-Augmented Generation (RAG) emerged to solve the most critical problem of deploying large models in enterprises: the model's knowledge is parameterized, static, and untraceable.

The basic idea of RAG is simple: first retrieve passages relevant to the question from external corpora, then feed those passages to the model as context to generate an answer. But in engineering practice, RAG has an extremely high failure rate, and the failure modes are subtle — answers look fluent and professional, yet the retrieved passages are actually unrelated to the question, or the relevant passages are buried in the middle of the context and never used.

The sources of RAG failure, ranked by impact, are usually:

1. Chunking: semantic units get severed, making the passages themselves unintelligible;
2. Retrieval: out-of-domain embedding models, or pure vector retrieval that misses keyword hits;
3. Assembly: retrieval is correct but placement is wrong, or the context exceeds budget;
4. Generation: the model free-wheels beyond the context.

The first three items all fall within the scope of Harness engineering; only the fourth is directly related to model capability. This is precisely the core thesis of this direction: most of the room for improving RAG quality lies in the engineering layer, not the model layer.

1.2. Definition

RAG (Retrieval-Augmented Generation): a technical system that, before generating an answer, first retrieves relevant passages from external corpora and assembles them into the context, grounding the generation process on traceable evidence.

A complete RAG pipeline consists of five stages:

1.3. Positioning in the AI Harness System

图 1-1｜RAG 六层能力模型：主层 L1 上下文工程、次层 L5 评估观测

数据来源：基于本文分析绘制的示意图。

In the Harness six-layer capability model, RAG is positioned as: primary layer L1 (Context Engineering), secondary layer L5 (Evaluation & Observability) (this mapping is the analysis of this document).

Bottleneck layer: RAG's bottlenecks are entirely in L1. The reasons are:

1. The essence of RAG is "deciding what the model sees," which is precisely the definition of L1's responsibility;
2. All of RAG's tunable parameters (chunking, embedding, fusion, reranking, Top-K, budget) are context-engineering parameters;
3. The vast majority of RAG failures cannot be fixed at the generation layer — once a relevant passage is not retrieved, even the strongest model can do nothing about it.

Why long context cannot replace RAG: this is the most misunderstood question in this direction. Three authoritative evidence chains give a negative answer:

• Lost in the Middle (Liu et al., TACL 2024): in multi-document QA, fixing the document count and moving the position of the answer-bearing document yields a U-shaped curve — accuracy is highest when the answer is at the head or tail and drops significantly in the middle; in some configurations, burying relevant information in the middle performs even worse than the model's closed-book performance, i.e., the retrieved context is a net negative.
• RULER (Hsieh et al., NVIDIA, COLM 2024): the original paper criticizes NIAH as being "indicative of only a superficial form of long-context understanding"; among the 17 long-context models evaluated, only about half maintain satisfactory performance at 32K length.
• NoLiMa (Modarressi et al., ICML 2025): after rewriting the needle to minimize literal overlap, among 13 models claiming support for ≥128K, 11 dropped below half of their own short-context accuracy at 32K; GPT-4o fell from 99.3% to 69.7%.

The boundary in reverse (when not to use RAG): Anthropic officially gives a rule of great engineering value — "If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt... with no need for RAG or similar methods."

Value: RAG is the most mature, most measurable, and most optimizable implementation in the L1 Context Engineering layer. It converts the uncontrollable question of "what the model knows" into the controllable question of "what we let the model see."

1.4. Technical Landscape & Key Parameters

Source reliability note: the quantitative values in 1.4.1 and 1.4.2 mostly come from SEO/aggregation content sites and have not been traced back to original sources such as Chroma Research, Weaviate, NVIDIA FinanceBench, OpenAI's official pricing pages, or the MTEB official leaderboard. They are therefore all marked [To be verified] and must not be directly cited as design basis; they can only serve as clues for tuning direction. Section 1.4.3 (Anthropic Contextual Retrieval) is first-party official data (R1) and can be cited directly.

1.4.1. Chunking

Analysis conclusion suitable for the main text: chunking is the first source of RAG failure, but its returns depend heavily on the corpus — parameters must be determined by measuring Recall@K on your own golden dataset, not by copying defaults. Note that "semantic chunking has better recall" and "semantic chunking has lower end-to-end accuracy" in the table point in opposite directions, which precisely shows that conclusions can reverse under different measures, further confirming the necessity of "must measure."

1.4.2. Retrieval & Reranking

1.4.3. Anthropic Contextual Retrieval (first-party official data, R1)

Source: Anthropic official blog https://www.anthropic.com/news/contextual-retrieval

The official text states: "This method can reduce the number of failed retrievals by 49% and, when combined with reranking, by 67%."

Metric definition: failure rate = 1 - recall@20, i.e., the "failure rate of not finding a relevant document in the top 20 retrieval results"; the test domains cover codebases, novels, ArXiv papers, and scientific literature.

Two-stage engineering workflow (official text):

• Offline preprocessing (one-time): chunk into blocks of a few hundred tokens → for each block, pass the full document + that block to Claude to generate a 50~100 token context description → prepend it to the block → generate a semantic embedding for the concatenated text → build a BM25 index on the concatenated text.
• Online inference: dual-recall with BM25 and vectors → Rank Fusion to merge and deduplicate → (optional) rerank the Top 150 candidates → take the Top 20 into the LLM.

Cost control (official text): using Prompt Caching, the full document is loaded only once and all blocks share the cache; the one-time preprocessing cost is about $1.02 per million document tokens.

This data point is the most valuable first-hand evidence in this direction: with the model unchanged, purely engineering means reduced the retrieval failure rate by 67%.

1.4.4. Evaluation Methodology

RAGAS (R1/R2, NVIDIA NeMo microservices documentation, Red Hat OpenShift AI documentation):

• Score range: context_recall ranges from 0 to 1, the higher the better.
• Dependencies: needs a Judge LLM; some metrics additionally require Judge Embeddings.
• Supports both offline (pre-generated answers) and online (auto-generated answers) evaluation modes.
• Practical usage: automated quality gates (triggered after every commit or model update to prevent regression), evaluation-driven development (comparing different chunking strategies/embedding models/retrieval algorithms), factual-consistency thresholds (setting a threshold on faithfulness), production scale-out (running thousands of samples in a distributed manner under the remote provider mode).

BEIR (R2, original paper arXiv:2104.08663, Thakur et al., NeurIPS 2021 Datasets and Benchmarks):

• 18 datasets, 9 categories of retrieval tasks: fact-checking, citation prediction, duplicate-question retrieval, argument retrieval, news retrieval, QA, tweet retrieval, bio-medical IR, entity retrieval.
• Primary metric nDCG@10, also computing MAP, Recall@k, Precision@k, MRR (k from 1 to 1000).
• Core methodological contribution: zero-shot evaluation — dense retrievers often beat BM25 in-domain but often lose cross-domain; BEIR exposes this generalization gap.
• Practical reminder: some datasets require authorization or manual download (TREC-NEWS, Robust04, Signal-1M, BioASQ); the publicly runnable subset is about 15~17, and "BEIR averages" computed over different subsets are not directly comparable.

MTEB / MMTEB (R2, original paper arXiv:2210.07316, Muennighoff et al.):

• Original MTEB: 8 task categories, 58 datasets, 112 languages; the metrics are respectively retrieval (nDCG@10), classification (accuracy), clustering (v-measure), pair classification (AP), reranking (MAP), STS (Spearman), summarization (Spearman), bitext mining (F1).
• MMTEB (Enevoldsen et al., ICLR 2025, arXiv:2502.13595): expanded to 500+ evaluation tasks, 250+ languages; the leaderboard is split by naming (English v2 / multilingual) and now uses Borda count ranking.
• Key advice for choosing models for RAG (R1-level methodology): "Quote the retrieval sub-score, not the overall MTEB rank." — for RAG scenarios you should look at the retrieval sub-score, not the overall rank.

2. Glossary

3. Case Studies

3.1. LinkedIn: Knowledge-Graph-Enhanced Customer Service RAG

3.1.1. Background

LinkedIn's customer service team needs to handle a large number of technical questions, and historical solutions are scattered across Jira tickets. The difficulty of plain-text RAG is that the relationships between tickets (cloned from, related to, caused by) carry a great deal of semantic information, which is lost after text chunking.

3.1.2. Approach

Based on the ZenML LLMOps database and Evidently AI's summary (R2, original source is an engineering talk):

• Build historical Jira tickets into a tree-shaped knowledge graph: nodes = Summary / Description / Priority / Steps to Reproduce / Fix Solution.
• Explicit relationships come from Jira metadata (cloned from / related to / caused by).
• Implicit relationships are built using E5 embedding cosine similarity + a threshold.
• GPT-4 handles parsing and generation; Qdrant stores the vectors.
• Deployed across multiple product lines, running in production for about 6 months.

3.1.3. Results

Based on the above source (R2):

The engineering takeaway of this case is: the combination of structured relationships + vector retrieval captures the semantic structure of ticket-like corpora better than pure vector RAG.

3.2. DoorDash: An Evaluation Closed Loop Built on Guardrails and an LLM Judge

3.2.1. Background

DoorDash's customer service chatbot faces end users directly, so a single wrong answer causes real business loss. Its technical focus is therefore not only on "answering accurately" but also on "being able to detect when it answered incorrectly."

3.2.2. Approach

Based on Evidently AI's summary (R2, original source is the DoorDash engineering blog):

• System architecture = RAG system + LLM Guardrail: monitoring the accuracy and compliance of every answer online.
• The LLM Judge evaluates along five dimensions: retrieval correctness, answer accuracy, grammatical/language accuracy, context coherence, and relevance to the user's request.

3.2.3. Results

This source does not disclose specific metric-improvement figures (R2). Its value lies in providing a replicable online evaluation structure: evaluating retrieval correctness and answer accuracy separately, so that "retrieval went wrong" and "retrieval was right but generation went wrong" can be distinguished and located — this is precisely the production counterpart of the design ideas behind evaluation frameworks such as RAGAS.

3.3. Bell: A Modular Document-Embedding Pipeline with Incremental Indexing

3.3.1. Background

Bell is a Canadian telecommunications operator whose document system is large and continuously updated. A one-time full rebuild of the index is unacceptable in both cost and latency.

3.3.2. Approach

Based on Evidently AI's summary (R2, original source is a conference talk video):

• Build a modular document-embedding pipeline supporting batch processing and incremental updates.
• Automatically update the index when documents are added or removed, avoiding full rebuilds.
• Each component is built and maintained as an independent service following DevOps principles.

3.3.3. Results

This source does not disclose quantitative metrics (R2). Its engineering value lies in clarifying RAG's operations-side requirements: the index is not a one-time artifact but a service that needs continuous evolution; incremental updates and component decoupling are necessary conditions for putting RAG into production.

Other reference cases (R2):

The Glean figures are vendor claims and must be labeled when cited.

4. Practical Standards

4.1. AGENTS.md Specification

The following is the full, copyable industry-standard AGENTS.md for the RAG direction, reflecting the specialized toolchain of vector stores, chunkers, embedding models, rerankers, and evaluation frameworks.

# AGENTS.md —— RAG（检索增强生成）

## 角色与边界
- 你是检索增强智能体，负责切分、索引、召回、重排、装配与评测。
- 你可以：读写索引、执行检索与重排、调整检索参数并提交评测、生成评测报告、调用脚本做跑分。
- 你不可以：在未见评测结果的情况下把参数变更推到生产、绕过权限过滤、
  把评测集混入索引语料、删除历史索引快照、编造评测数值。
- 判定原则：任何影响检索结果的变更，必须先评测后上线。

## 环境假设
- 运行环境提供：向量库、BM25 索引、嵌入服务、重排服务、切分器、
  评测框架（RAGAS / 自有黄金集）、对象存储（索引快照）、Trace 与审计日志。
- 语料具备版本/快照标识；索引具备版本号，可与语料版本对应。
- 检索服务在召回阶段即完成权限过滤（permission-aware retrieval）。
- 具备上下文预算读数（已装配 Token 数 / 上限）。

## 上下文加载顺序（Context Budget）
1. 查询与任务契约（常驻，不压缩）
2. 检索配置：切分参数、嵌入模型、融合方式、重排模型、Top-K（常驻）
3. 候选集（重排后的 Top-K，附 doc_id + 版本 + 片段定位）
4. 会话历史（多轮时，压缩为要点）
5. 参考示例（按需）
- 装配上限：默认低于 8K tokens；关键信息置于首部或尾部，不得埋在中部。
- 关键片段优先，低相关片段先被裁剪。

## 工具契约
- 切分器：递归 / 语义 / 层次化；参数必须由自有黄金集实测确定，不得照搬默认值。
- 向量库：写入前校验幂等；索引变更生成新版本快照；旧快照保留可回溯。
- 检索：默认向量 + BM25 混合召回 + RRF 融合；纯向量检索不得作为生产默认。
- 重排：候选集进入上下文前做 cross-encoder 重排；重排阈值写入配置。
- 评测：RAGAS（context_recall / context_precision / faithfulness / answer_correctness /
  noise_sensitivity）+ 自有黄金集；需要 Judge LLM 与 Judge Embeddings。
- 脚本：切分、跑分、批量评测、格式转换必须调用 scripts/，不得用生成方式替代。

## 任务执行流程（SOP）
1. 定界：语料白名单与版本、密级、查询类型（事实型 / 分析型 / 多跳）。
2. 判定模式：语料 < 200,000 tokens 走全量装配，不做切分召回。
3. 检索：向量 + BM25 → 权限过滤 → RRF 融合 → 重排 → Top-K。
4. 装配：按预算组织上下文；关键信息首尾放置；标注来源标识。
5. 生成：逐条陈述挂来源标识；无召回支撑不输出事实性结论。
6. 评测：任何参数变更先在黄金集上跑 Recall@K 与忠实度，与基线对比。
7. 上线：指标不低于基线方可上线；记录基线变化与变更日志。
8. 回流：把失败查询与人工修正加入评测集与负样本。

## 验证与证据要求
- 证据包：来源清单（doc_id + 版本 + 片段定位）、检索记录（查询、召回数、
  重排 Top-K、权限过滤命中数）、评测报告（指标 + 基线对比）、变更日志、索引版本快照。
- 引用外部基准时须注明所跑子集与指标口径（不同 BEIR 子集的均值不可直接比较）。
- 嵌入模型选型须引用 retrieval 子分，而非 MTEB/MMTEB 总排名。

## 失败与升级策略
| 失败 | 处置 |
|---|---|
| 检索零命中 | 输出"未检索到可靠依据"；检查索引版本与查询改写；禁止自由生成 |
| 召回正确但答案错误 | 检查装配位置与上下文预算；提高忠实度阈值 |
| 参数变更导致指标回退 | 回退上一配置；重新评测；记录归因 |
| 权限过滤命中异常 | 停止检索，记录审计事件，升级至权限管理员 |
| 索引与语料版本不匹配 | 暂停服务，重新索引并校验 |
| 评测不可比 | 固定子集、模型版本与随机种子；注明口径 |
- 每个循环必须有步数上限与 Token 预算上限；超限即停并升级。

## 安全与合规红线
- 不得绕过权限过滤；不得使用高权限账号做检索。
- 不得把评测集混入索引语料造成数据污染。
- 不得删除历史索引快照；不得编造评测数值。
- 未经评测通过的检索配置不得推到生产。

## 禁止事项
- 禁止照搬默认切分参数（400~512 tokens + 10%~20% 重叠仅为线索，须实测）。
- 禁止把 `[待核实]` 的聚合站数值当作设计依据。
- 禁止用纯向量检索作为生产默认。
- 禁止在无召回支撑时输出事实性结论。
- 禁止编造 doc_id、版本号、评测指标与 URL。
- 禁止使用 XX / XXX / ___ 等非标准占位符（统一用 [待填写] / [待核实]）。
- 禁止使用 emoji 与署名。

## 输出格式
- 检索结果：片段内容 + 来源标识 + 相似度/重排分 + 用于哪一论点。
- 评测报告：指标 / 基线 / 当前值 / 差值 / 是否通过门控 / 口径说明。
- 数值带单位；范围用 ~ 连接；中文全角标点；中英文之间加空格。

## 评估与自检
- 九项自检：来源可回溯 / 无无源断言 / 数值一致 / 无非标占位符 / 数量与表格一致 /
  编号可核实 / 密级正确 / 评测已跑且可比 / 信息缺口已声明。
- 每次索引或模型变更后重跑评测集；指标回退视为缺陷。
- 失败查询与人工修正必须回流进评测集。

4.2. SKILL.md Specification

The following is the full, copyable industry-standard SKILL.md for the RAG direction.

---
name: rag-eval
description: 构建 RAG 评测集并在切分/嵌入/融合/重排/装配变更后跑分，产出与基线的对比报告与上线门控结论。当用户要求"评测这套检索""对比两种切分策略""换嵌入模型后效果如何""生成 RAG 回归报告""为什么这条查询召回不到"时触发。
version: 1.0
created: 2026-09-12
---

# RAG 评测与调优（RAG Evaluation & Tuning）

## 适用场景
- 构建与维护黄金集（Golden Dataset）与负样本集。
- 切分参数、嵌入模型、融合方式、重排模型、Top-K 的对比评测。
- 索引或语料大版本更新后的回归验证。
- 单条查询召回失败的归因分析。

## 前置条件
- 已有基线指标（Recall@K、context_recall、faithfulness 等）与对应的配置快照。
- 评测集版本固定，且未混入索引语料。
- 运行环境提供 Judge LLM 与 Judge Embeddings。
- 已确定指标口径与门控阈值。

## 输入
- 待评测配置：切分参数 / 嵌入模型 / 融合方式 / 重排模型 / Top-K / 装配预算
- 评测集版本与门控阈值
- 可选：失败查询清单（用于归因分析）

## 输出
- 评测报告：指标 / 基线 / 当前值 / 差值 / 是否通过门控 / 口径说明
- 归因分析：失败查询归类（切分问题 / 召回问题 / 重排问题 / 装配问题）
- 上线建议：通过 / 回退 / 需人工裁决
- 评测集更新建议：新增负样本与边界用例

## 执行步骤
1. 固定变量：一次只变更一个因素，其余保持不变。
2. 跑检索侧指标：Recall@K、context_recall、context_precision、context_entity_recall。
3. 跑生成侧指标：faithfulness、response_relevancy、response_groundedness。
4. 跑综合与鲁棒性：answer_correctness、noise_sensitivity。
5. 与外部基准对齐（可选）：BEIR 子集（注明子集与 nDCG@10 口径）、
   MTEB/MMTEB retrieval 子分（**引用子分，不引用总排名**）。
6. 对比基线，输出是否通过门控；未通过则回退并归因。
7. 把失败查询归类：切分 / 召回 / 重排 / 装配，并加入评测集。
8. 产出报告与变更日志；记录索引版本快照。

## 质量标准（DoD）
- 一次只变更一个变量，配置快照完整可复现。
- 指标口径明确；引用外部基准时注明子集。
- 与基线的差值、统计窗口、样本量均已披露。
- 失败查询已归类并进入评测集。
- 通过门控才可给出上线建议。

## 常见失败与处理
| 失败 | 根因 | 处置 |
|---|---|---|
| 指标不可比 | 子集/口径/模型版本变化 | 固定变量重跑；注明口径 |
| 检索好但生成差 | 装配位置或预算问题 | 关键信息首尾放置；压缩低相关片段 |
| 生成好但检索差 | 评测集过易或样本偏差 | 补充难样本与负样本 |
| 评测结果不稳定 | Judge 模型/随机性 | 固定 Judge 模型与种子；多次取均值 |
| 线上与离线不一致 | 索引版本不匹配 | 校验线上索引版本与评测时一致 |
| 换嵌入模型无提升 | 引用了总排名而非 retrieval 子分 | 改看 retrieval 子分与域内召回 |

## 示例
用户请求：把切分从 512 tokens/15% 重叠改为 1024 tokens/20% 重叠，评估是否可上线。
执行：
1. 固定嵌入模型、融合方式、重排模型、Top-K=20、装配预算 8K tokens。
2. 在黄金集（v1.3，300 条）上跑 Recall@20、context_recall、context_precision。
3. 跑生成侧 faithfulness 与 answer_correctness（Judge 模型固定）。
4. 对比基线：Recall@20 由 0.81 变为 0.79（-0.02），faithfulness 由 0.92 变为 0.91。
5. 结论：未通过门控（Recall 回退），建议回退 512/15% 配置。
6. 归因：长块稀释了事实型查询的信号；把 12 条失败查询加入评测集。
7. 输出报告：指标表 + 口径说明 + 回退建议 + 变更日志。
约束：禁止在未跑评测的情况下给出"建议上线"结论；禁止引用聚合站数值作为依据。

4.3. Implementation Checklist

5. Summary

RAG is the direction in the knowledge-collaboration group with the highest technical density, the most complete evaluation system, and the most easily underestimated engineering complexity.

The five most important conclusions of this direction:

1. The returns from engineering means can be quantified and are enormous. Anthropic's official data shows Contextual Retrieval lowers the Top-20 retrieval failure rate from 5.7% to 2.9% (-49%), and to 1.9% (-67%) when combined with reranking, while the one-time preprocessing cost is only about $1.02 per million document tokens (R1). This was achieved with the model unchanged.
2. Long context is not a substitute for RAG. The U-shaped effect of Lost in the Middle, RULER's evaluation of 17 long-context models (only about half maintain satisfactory performance at 32K), and NoLiMa's evaluation of 13 models supporting ≥128K (11 drop below half of their own short-context accuracy at 32K) together show that piling on context can produce a net negative return.
3. Small corpora should go directly and entirely into the prompt. Anthropic officially states: < 200,000 tokens (about 500 pages) requires no RAG. This rule can significantly reduce complexity for small teams.
4. Evaluation is a release gate, not an after-the-fact report. RAGAS measures the retrieval side and the generation side separately, so that "retrieval went wrong" and "generation went wrong" can be distinguished and located; BEIR emphasizes zero-shot cross-domain evaluation, and MTEB/MMTEB emphasizes citing the retrieval sub-score rather than the overall rank.
5. Chunking is the first source of failure, but there is no universal optimum. In public data, "semantic chunking has better recall" and "semantic chunking has lower end-to-end accuracy" point in opposite directions, showing that you must measure on your own golden dataset.

We must candidly point out that, in the parameter space of chunking and retrieval for this direction, the vast majority of public figures come from SEO/aggregation content sites and have not been traced back to Chroma Research, Weaviate, NVIDIA FinanceBench, OpenAI's official pricing pages, or the MTEB official leaderboard. These figures have been fully marked [To be verified] in 1.4.1 and 1.4.2 and should not be used as design basis; they can only serve as clues for tuning direction. The only truly trustworthy quantitative anchors are the Anthropic Contextual Retrieval set (R1).

Information-Gap Statement

6. References

1. Introducing Contextual Retrieval — Anthropic, 2024. https://www.anthropic.com/news/contextual-retrieval
2. RAGAS Metrics — NVIDIA NeMo Microservices documentation. https://docs.nvidia.com/nemo/microservices/latest/evaluator/metrics/rag.html
3. Evaluating AI Systems (RAGAS practical usage) — Red Hat OpenShift AI documentation. https://docs.redhat.com/en/documentation/red_hat_openshift_ai_self-managed/3.3/html-single/evaluating_ai_systems/
4. BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models — Thakur et al., NeurIPS 2021 (arXiv:2104.08663). https://arxiv.org/abs/2104.08663
5. MTEB: Massive Text Embedding Benchmark — Muennighoff et al. (arXiv:2210.07316). https://arxiv.org/abs/2210.07316
6. MMTEB: Massive Multilingual Text Embedding Benchmark — Enevoldsen et al., ICLR 2025 (arXiv:2502.13595). https://arxiv.org/abs/2502.13595
7. Lost in the Middle: How Language Models Use Long Contexts — Liu et al., TACL 2024. https://arxiv.org/abs/2307.03172
8. RULER: What's the Real Context Size of Your Long-Context Models? — Hsieh et al., COLM 2024. https://arxiv.org/abs/2404.06654
9. NoLiMa: Long-Context Evaluation Beyond Literal Matching — Modarressi et al., ICML 2025. https://arxiv.org/abs/2502.05167
10. Needle in a Haystack — Pressure Testing LLMs — gkamradt/LLMTest_NeedleInAHaystack. https://github.com/gkamradt/LLMTest_NeedleInAHaystack
11. Knowledge Graph-Enhanced RAG for Customer Service QA (LinkedIn case) — ZenML LLMOps Database. https://zenml.io/llmops-database/knowledge-graph-enhanced-rag-for-customer-service-question-answering
12. RAG Examples (DoorDash / Bell / HBS / Vimeo / Grab / Pinterest roundup) — Evidently AI. https://evidently.ai/blog/rag-examples
13. Glean — Enterprise AI platform official site (vendor-claimed data). https://www.glean.com
14. Qdrant — Vector database (used in the LinkedIn case). https://qdrant.tech/