一、什么是「大模型生成式搜索」？

一句话：
用户用自然语言提问 → 系统先检索相关资料 → 再让大模型阅读这些资料并生成答案 → 给出带引用的、有结构的回答，而不是只给你一堆链接。

和传统搜索对比：

• 传统搜索：
  • 核心是“匹配关键词”
  • 返回的是“文档/网页列表”
  • 由用户自己点开、阅读、总结
• 生成式搜索：
  • 核心是“理解语义 + 生成回答”
  • 先找资料，再总结、归纳、对比
  • 返回的是“直接可读的答案 + 引用来源”

核心关键：
不是大模型“凭空乱想”，而是大模型“在检索到的资料上做总结” → 这就是常说的 RAG：Retrieval-Augmented Generation（检索增强生成）。

二、整体流程：从提问到回答的完整链路

用一个简单的流程图来理解：

1. 用户提问：
   • “大模型生成式搜索是怎么实现的？”
2. 系统理解问题 → 解析需求、抽取关键词、识别意图
3. 去知识库/互联网里检索相关内容（文档、网页、API等）
4. 选出最相关的一批内容（Top K）
5. 把问题 + 资料喂给大模型，让它“读完再回答”
6. 大模型生成结构化回答，并附上引用
7. 返回给用户，界面可以支持追问、继续对话

用一句类比：
传统搜索像去图书馆找书；生成式搜索像请一个很懂行的图书管理员，帮你把书找好并读完，给你讲重点。

三、底层关键技术模块总览

大模型生成式搜索 = 多个模块协同工作：

1. 前端交互层
   • 聊天界面 / 搜索框 / API
2. 业务编排 & Orchestration（流程编排）
   • 决定什么时候检索、什么时候调用大模型、怎么组合结果
3. 检索系统（搜索引擎部分）
   • 索引构建（倒排索引 + 向量索引）
   • 召回（BM25 / 向量检索 / 混合检索）
   • 排序（Re-ranking）
4. 向量数据库 / 语义索引
   • 文本嵌入、向量存储、相似度搜索
5. 大语言模型（LLM）
   • GPT、LLaMA、Qwen 等
   • 负责阅读、理解、总结、生成
6. RAG 逻辑层（检索增强生成）
   • Prompt 构造、上下文拼接、引用控制、反事实检测等
7. 安全与质量控制
   • 防幻觉、防隐私泄露、不当内容过滤
8. 监控 & 反馈 & 优化
   • 日志、用户反馈、在线学习

四、核心一：检索系统是“眼睛”，负责找到可靠资料

大模型再聪明，也得有“材料”可读。检索就像是它的“眼睛”。

4.1 索引是怎么建的？

通常有两类索引：

1. 倒排索引（Inverted Index）——传统搜索的基石

   • 把每个词出现在哪些文档里记下来
   • 适合关键词匹配、布尔检索、BM25 等传统算法
   • 优点：快、成熟、可解释
   • 缺点：对语义理解有限，词不同就找不到（如“车”和“汽车”）

2. 向量索引（Vector Index）——语义检索的基石

   • 每段文本变成一个向量（Embedding），比如 768 维
   • 一段话的向量接近，就认为语义相近
   • 使用向量数据库（Faiss、Milvus、pgvector、qdrant 等）
   • 优点：能理解语义相似，不怕词不完全一样
   • 缺点：近似搜索，有误差；维护成本高

实践中：
大多用“混合检索”——倒排 + 向量，两者结果再融合。

4.2 文档预处理：切块、向量化

一个文档太长，大模型上下文放不下，因此一般要：

1. 分段 / 切块（chunking）
   • 按段落、按标题、按固定长度（比如 300~800 tokens）
   • 可能还会做“滑动窗口”切块，避免切断上下文
2. 对每个块做向量化（Embedding）
   • 用专门的 embedding 模型（如 text-embedding-3-large 等）
   • 存到向量数据库里，附带元数据（来源、时间、标签等）
3. 在倒排索引里，也用段级粒度建立索引
   • 可更精细地检索到“某一段”

这样，将来检索时，可以直接找到“最相关的几个段落”，而不是整篇长文。

4.3 查询时是怎么“找资料”的？

假设用户问题是：“详细介绍大模型生成式搜索实现原理和技术架构”。

通常流程：

1. Query 预处理

   • 分词、去停用词、拼写纠错、同义词扩展
   • 可能还用小模型先识别意图、领域

2. 向量检索

   • 用 embedding 模型把问题变成向量 q
   • 在向量索引里找“最相似的 K 个文档块”
   • 相似度可以是 cosine / dot-product 等

3. 关键词检索（倒排）

   • 用 BM25 等在常规搜索引擎（ElasticSearch、OpenSearch、Solr、自研）中检索
   • 也得到一批候选文档块

4. 结果融合

   • 把向量检索结果 + 关键词检索结果融合
   • 常见做法：
     • 简单加权：score = a * semantic_score + b * keyword_score
     • 学习排序：用训练好的模型决定最终排序

5. Re-ranking（重排序）

   • 用更强一点的模型（如 cross-encoder、mini-LM）对候选文档与查询逐对计算“相关性”，重新排序
   • 这样精度更高，只是稍慢，但只对 Top-N 做即可

最后得到：一批按相关性排序的“文档片段” + 元数据。

五、核心二：大模型是“大脑”，负责理解和生成答案

有了资料，还需要有人“看懂并讲出来”——大模型就是这个角色。

5.1 RAG（检索增强生成）的基本套路

典型的 Prompt 结构：

角色：
你是一个专业的 XXX 领域助手。

背景资料（检索到的内容）：
[文档1片段]
[文档2片段]
…

用户问题：
[用户的原始问题]

要求：

• 只基于上述资料回答
• 不要编造资料中没有的信息
• 用通俗语言解释，并给出关键要点
• 在回答中用【[1]】【[2]】标注引用来源

模型看到的是：一个“问题 + 多段相关资料 + 明确的指令”。
它的任务就是：在这些资料的范围内组织答案，而不是随意发挥。

5.2 上下文拼接与“引用长度”问题

LLM 有上下文长度限制（比如 8K、32K、128K tokens 等），所以：

• 检索到的文档块不能全塞，通常只放 Top-K（例如 5～20 段）
• 还要控制每段文本长度，做摘要或截断
• 有些系统会先对长文做“多级摘要”（分层 RAG）：
  • 先检索到几篇长文 → 对每篇做段内摘要 → 再把摘要给 LLM

当问题复杂、需要跨多个文档时，可能采用：

• 多轮 RAG：模型先分解子问题 → 每个子问题单独检索 → 最后汇总
• Graph RAG / 知识图谱结合：先从文档构建概念图，再沿图检索更精准的知识点

5.3 防“乱编”：约束大模型的几种手段

1. Prompt 中明确写：只能依据给定资料，不要随意猜测
2. 让模型对答案中每一段，尽量附加引用来源
   • 没有来源的内容权重更低，甚至可以过滤
3. 答案后处理：事实检查 / Consistency Check
   • 如：用另一次检索校验核心事实
   • 或用一个“评审模型”评估答案是否与资料一致

六、技术架构：从系统视角看整体设计

可以想象一个简化架构（逻辑层次）：

6.1 在线服务主链路

1. API 网关 / 前端
   • 接收用户请求，做鉴权、限流
2. 对话管理 / 请求编排层（Orchestrator）
   • 判定请求类型：问答、聊天、代码解释、工具调用等
   • 负责：
     • 是否需要检索？
     • 调哪个搜索引擎？
     • 调哪个大模型？（大模型路由）
     • 是否调用工具（计算器、数据库、业务系统）？
3. 检索服务层
   • Query 分析、召回、重排
   • 访问：
     • 文本库（文档、知识库）
     • 向量数据库
     • 网页抓取 / Web 搜索接口
4. 上下文构建 & Prompt 工程层
   • 把用户问题 + 检索结果 + 系统指令 拼好 Prompt
   • 控制内容长度、格式、引用
5. 大模型服务层（LLM Service）
   • 本地部署 / 云端 API
   • 有模型路由、负载均衡、多模型管理
6. 结果后处理层
   • 引用格式化、高亮、分段标题
   • 敏感内容过滤（安全策略、合规）
7. 返回前端

6.2 离线/批处理部分（支撑系统）

1. 数据采集 & 清洗
   • 爬虫、文档上传、业务数据同步
   • 去重、去广告、去噪声
2. 文档解析 & 切块
   • PDF/Word/网页 → 结构化文本 → 按块切分
3. 向量化 & 索引构建
   • 调用 embedding 模型生成向量
   • 写入向量数据库
   • 建立倒排索引（ES 等）
4. 质量评估 & 标注
   • 人工/半自动标注问答对
   • 评估检索质量、模型回答质量
5. 模型训练 / 微调 / 对齐
   • 针对领域数据做 SFT/LoRA
   • 训练重排序模型、意图识别模型、安全过滤模型等

七、在真实系统中的一些关键“工程问题”

7.1 延迟与性能

• 检索 + 大模型生成，时间可能较长
• 常用优化：
  • 检索和模型调用并行或流水线
  • 缓存热点问题的答案
  • 用小模型做预判，大模型做“高价值问题”
  • 使用 streaming 流式输出，先让用户看到部分内容

7.2 成本控制

• LLM 接口价格高 → 尽量减少不必要调用：
  • 问题很简单时直接检索 + 模板回答
  • 使用小模型做简单问题
  • 对重复问题使用缓存

7.3 安全与合规

• 敏感内容过滤：
  • 在输入前做用户请求过滤（如禁止违法内容）
  • 在输出后做内容审核过滤（暴力、色情、仇恨等）
• 隐私保护：
  • 不将敏感用户数据用于模型训练
  • 企业内网部署时，确保数据不外流

7.4 评估与迭代

• 评估指标：
  • 检索质量：召回率、精确率、nDCG
  • 回答质量：正确性、完整性、可读性、引用准确度
• 常用方法：
  • 人工评测（专家打分）
  • A/B 测试
  • 结合用户行为（是否追问、是否点来源链接）

八、几种典型的应用场景架构差异

8.1 通用互联网搜索（如 Perplexity部分新版搜索引擎）

• 数据来源：全网网页 + 新闻 + wiki
• 强调实时性：
  • 增量爬取、实时索引
• 更复杂的查询理解和多轮对话：
  • 比如“帮我比较 iPhone 16 和 小米 15 的配置”

8.2 企业知识库搜索 / 内部问答

• 私有数据：内部文档、会议纪要、知识库、代码仓库
• 重点是：
  • 权限控制（不同角色看到不同文档）
  • 与业务系统集成（工单系统、CRM、ERP）
  • 高准确率 + 审计可追踪

8.3 垂直领域搜索（法律、医疗、金融等）

• 数据更专业，容错率更低
• 通常会：
  • 用领域大模型或微调模型
  • 加强规则校验（如引用条款号、药品说明书等）
  • 增加“不能回答”机制：不确定就拒答或提示风险

九、自己搭一个简化版生成式搜索，需要哪些步骤？

1. 数据准备

   • 收集若干 PDF/Markdown/网页
   • 提取文字，并按段落/标题切块

2. 向量和索引

   • 选一个向量数据库（如 qdrant / Milvus / pgvector）
   • 用 OpenAI embedding 或其他 embedding 模型将块向量化
   • 建立普通全文索引（如 ES / OpenSearch）可选

3. 简单检索服务

   • 写一个后端服务（Python/FastAPI 或 Node 等）
   • 输入：问题
   • 输出：Top-K 文本块 + 相关性得分

4. RAG 聚合层

   • 在后端拼装 Prompt：
     • 系统指令 + Top-K 文本 + 用户问题
   • 调用大语言模型 API（如 GPT-4.1）
   • 返回模型回答

5. 前端界面

   • 简单的聊天框
   • 下方列出引用的文档段落和原始链接

6. 迭代优化

   • 调整 chunk 大小、Top-K 数量
   • 增加 Re-ranking
   • 调 Prompt 让引用更准确

十、倒排索引和向量索引详细介绍

可以把“搜索”想象成在一个巨大的图书馆里找书：

• 倒排索引：
  像一本“关键词 → 书和页码”的字典。
  你查“生成式搜索”，它告诉你：哪几本书、哪几页出现过这个词。

• 向量索引：
  把每一段文字变成一个“语义坐标点”，放在一个看不见的空间里。
  你问一个问题，它也变成一个点，然后系统在这个空间里找离它最近的点——这些点对应的段落，就是“语义上最相似的内容”。

一句话概括：

• 倒排索引：“哪个词在哪儿出现过” → 更偏“字面匹配”
• 向量索引：“哪段话跟这句话说的是类似的意思” → 更偏“语义匹配”

10.1 倒排索引：传统搜索引擎的“关键词目录”

倒排索引的核心思想

倒排索引（Inverted Index）这个名字容易劝退，其实非常简单：

• 正排：文档 → 里面有哪些词
• 倒排：词 → 出现在了哪些文档里

为什么叫“倒排”？
因为它把“文档里有啥词”这个关系倒过来，按“词”来作为查找入口。

类比：

• 正常记笔记：
  「第1篇文章：有‘大模型’、‘搜索’、‘RAG’」
  「第2篇文章：有‘搜索’、‘PageRank’」
• 倒排笔记：
  「大模型：出现在 文档1」
  「搜索：出现在 文档1、文档2」
  「RAG：出现在 文档1」
  「PageRank：出现在 文档2」

当你搜索“搜索 RAG”时，只要看：

• “搜索” → 文档1、2
• “RAG” → 文档1
• 两者交集 → 文档1
  就知道文档1最相关。

倒排索引是怎么构建的？

简单版流程：

1. 文本预处理

   • 分词：把“我喜欢生成式搜索”变成 [我, 喜欢, 生成式, 搜索]
   • 小写化、去标点、去停用词（的、了、和……）

2. 为每篇文档分配一个文档 ID（docID）
   例如：doc1, doc2, doc3…

3. 扫每篇文档，记录每个词出现在哪些文档里
   形成这样的结构：

   “生成式” → [doc1, doc5, doc20]
   “搜索”   → [doc1, doc2, doc8, doc20]
   “大模型” → [doc1, doc3]
   

4. 可以进一步记录：

   • 出现次数（Term Frequency）
   • 出现位置（哪个字段、哪一行）
     方便后续做排序和高亮。

这个“词 → 文档列表”的结构，就是典型的倒排索引。

查询时倒排索引怎么用？

例子：用户搜索 “大模型 搜索 原理”。

1. 同样先做分词、清洗 → [大模型, 搜索, 原理]
2. 从倒排索引查：
   • “大模型” → [doc1, doc3, doc7]
   • “搜索” → [doc1, doc2, doc7, doc9]
   • “原理” → [doc1, doc5, doc7]
3. 做集合运算：
   • 交集（AND）：三个词都出现 → [doc1, doc7]
   • 并集（OR）：至少一个词出现 → [doc1, doc2, doc3, doc5, doc7, doc9]
4. 对候选文档打分排序：
   • 词出现得越多、越重要的位置（标题、开头） → 得分越高
   • 使用典型公式：TF-IDF、BM25 等

最终按得分排序，把最相关的文档列表返回给用户。

倒排索引的优点与局限

优点：

1. 高效成熟：

   • 对大规模数据（几十亿条文档）依然能快速搜索
   • 所有传统搜索引擎（Google、ES、Solr）都以此为核心

2. 可解释性强：

   • 你能说清楚某个结果为什么匹配（包含哪些词）

3. 支持复杂检索逻辑：

   • “必须包含 A，不包含 B，时间在某段区间，作者是某人”等

局限：

1. 只懂词面，不懂语义

   • 问 “汽车保养” 时，可能漏掉只写“车辆维护”的文档
   • 同义词、近义词、多语言问题都很麻烦，需要额外的同义词词典、规则等

2. 对自然语言问题不友好

   • 如 “为什么我家猫不吃东西” 这样的问句，倒排只能拆成若干关键词来匹配，很难理解“真正意图”

3. 无法自然处理“相似意思但用词不同”的情况

   • 用户说“模型是怎么记住知识的？”
   • 文档里写“参数中编码了统计规律”
   • 字面差异很大，但语义其实相关，倒排难以捕捉。

10.2 向量索引：让机器“按意思”来找东西

倒排索引按“词”来找，向量索引按“意义”来找。

什么是“向量表示”？

在向量索引中，每一段文本不会只被当成“字串”，而是被转成一个高维向量。

可以理解为：

• Embedding 模型给每段文本一个“语义坐标”
• 维度可以是 256、768、1024……（取决于模型）
• 相似的意思，其向量就“靠得近”

类比：

• 把电影按“风格维度”来表示，比如：
  • 喜剧程度、动作程度、爱情程度、科幻程度、年代感……
• 一部电影就变成一个点
• 喜欢《星际穿越》的用户，再找“相似电影”，就是找在这个空间里离它近的点。

文本向量是类似的，只不过维度多得多，而且是模型自动学习的。

向量索引是怎么构建的？

构建向量索引的基本步骤：

1. 文本预处理和切块

   • 和前面 RAG 一样：把文档切成合适长度的块（段落/小节）

2. 使用 Embedding 模型将每个块转成向量

   • 比如某模型输出 768 维向量
   • 得到一个形如 [0.13, -0.27, 0.05, …] 的浮点数组

3. 把这些向量和原始文本一起存入向量数据库

   • 常见选型：Faiss、Milvus、qdrant、pgvector 等
   • 向量库会建立“近似最近邻索引”（ANN Index），比如 HNSW、IVF 等，用于快速找到相似向量

结果就是：
“向量空间里的一个点” ↔ “某段具体文本” 的一一对应表。

查询时向量索引怎么工作？

假设你问：“如何实现大模型生成式搜索？”

1. 把这个问题用同一个 Embedding 模型转成一个向量 q

2. 在向量数据库里执行“相似搜索”：

   • 找所有向量中，和 q 距离最近的 K 个
   • 距离度量常用：
     • 余弦相似度（cosine）
     • 内积（dot product）
     • 欧氏距离（L2）等

3. 找到最相近的若干文本块，并返回这些块作为“检索结果”

这些结果不一定包含你的问题里的关键词，但“说的是同一回事”。
比如：

• 问：“大模型怎么和搜索引擎结合？”
• 文档里写的是：“RAG（检索增强生成）将LLM与信息检索系统集成……”
• 关键词不同，但语义接近 → 向量搜索就能找到。

向量索引的优点与局限

优点：

1. 语义级匹配

   • 不需要关键词完全一致，也能找出相同意思的内容
   • 对同义词、近义表达、不同语言（跨语言 embedding）有天然优势

2. 对自然语言查询更友好

   • 用户可以随便用口语提问
   • 系统根据语义理解，找到对应知识点

3. 可以统一表示多种模态

   • 文本、图片、音频都可以转成向量
   • 从文本找图片（“猫在沙发上睡觉”→ 找对应图片）

局限：

1. 计算和存储成本较高

   • 每个文本块要存一个高维向量
   • 相似搜索需要专门的索引结构和算法

2. 精准控制能力弱

   • 很难做到“必须包含某个具体词”“排除某个词”这种严格过滤
   • 很难做复杂的布尔逻辑条件

3. 可解释性差

   • 很难给用户解释“为什么这段结果被认为相似”
   • 向量空间本身对人类不可见

4. 质量高度依赖 embedding 模型

   • 模型好 → 向量表示语义清晰 → 检索准确
   • 模型差 → 检索结果会“语义跑偏”

10.3 现实系统中常用的“混合检索”

在实际的大模型生成式搜索系统里，往往不是二选一，而是两者结合：

1. 用户提问 Q（自然语言）
2. 向量召回：
   • 用 embedding 模型把 Q 变成向量 q
   • 在向量索引里找出语义上最相近的 Top N 个文档块（粗筛）
3. 倒排 + Re-ranking 精排：
   • 用倒排索引找“包含关键字”的相关文档块
   • 合并召回结果 → 得到候选集
   • 用重排模型（re-ranker）对 [Q, 文档块] 一对一打分，重新排序
   • 再筛出 Top K 个“最靠谱、最匹配”的文档块
4. 丢给大模型生成答案：
   • 把 Q + Top K 文档块 + 指令 组成一个 Prompt
   • 让大模型在这些资料基础上生成结构化回答，并尽量引用来源。

用向量索引做“召回”：先大致找对方向

为什么第一步要用“向量召回”？

因为用户的问题常常是自然语言 + 口语 + 模糊意图，例如：

“怎么用大模型+搜索给用户更直接的答案？”

你的文档里可能是这样写的：

“本文介绍的是 RAG（检索增强生成）系统架构，将 LLM 与检索引擎结合……”

关键词很难完全对上（“大模型+搜索” vs “RAG + LLM + 检索引擎”），
但语义其实非常接近。传统倒排基于关键词，容易漏掉这些“错位但同义”的内容。

向量召回的目标：
只要意思接近，就能先拉进候选集里。
这一阶段不要求“特别精准”，只要把大方向对的都找上来。

向量召回的原理:

1. 训练好（或使用现成的）Embedding 模型

   • 输入一句话（文本块），输出一个固定长度的向量，例如 768 维
   • 这个向量可以理解为这句话的“语义坐标”

2. 构建向量索引

   • 对每个文档块都做一次 embedding → 得到向量 v_i
   • 把 {向量 v_i, 文本内容, 文档ID, 其他元数据} 存入向量数据库
   • 向量数据库内部建“近似最近邻索引”（ANN），用图结构 / 聚类等方法加速“找最近的向量”

3. 查询时

   • 把用户问题 Q 用同一个 embedding 模型变成向量 q
   • 在向量库中寻找与 q 距离最近的 N 个向量 v_i
   • 获取对应的 N 个文档块（记为候选集合 C_vector）

距离怎么测？常见有：

• 余弦相似度（cosine similarity）
• 点积（dot product）
• 欧式距离（L2 distance）

向量越近 → 语义越相似。

用倒排 + Re-ranking 提升精度：从“大致相关”到“真正相关”

有了向量召回的候选集合C_vector， 接下来会遇到两个问题：

1. 向量召回有“噪声”：

   • 有些文档在语义空间里看起来接近，但其实与你的问题不那么匹配
   • 例如问“搜索系统中的 RAG 架构”，可能召回“推荐系统中的召回策略”——听起来都有“召回”，但语境不同

2. 还需要结合“关键词”和其他约束：

   • 必须包含某些关键词
   • 某些时间范围 / 作者 / 业务系统等过滤条件
   • 这类结构化过滤，倒排系统更擅长。

所以我们引入：倒排检索 + Re-ranking。

倒排检索：补充另一批候选 & 支持过滤

倒排检索会做几件事：

1. 对同一个问题 Q 按关键词拆解，执行 BM25 等搜索
2. 得到另一个候选集合 C_bm25（关键词匹配较好的文档块）
3. 支持各种过滤条件（比如只看某产品线、某时间之后的文档、只看你有权限的文档）

然后：

• C_all = C_vector ∪ C_bm25
• 再根据一些逻辑做去重（同一文档块不要重复）

为什么要两套召回？

• C_vector：保证语义召回（即使关键词不完全一致）
• C_bm25：保证关键词控制 & 精准匹配（重要专有名词、ID、代码等不漏）

Re-ranking（重排序）：用小模型精细打分

你现在有了一批候选文档块 C_all，但它们的排序：

• 一部分是按向量相似度排的
• 一部分是按 BM25 等关键词相关度排的

这两套打分的指标和尺度不同，不太好直接比较，因此需要一个统一的“裁判”：重排序模型。

原理上是这样：

1. 重排模型一般是个小一点的 Transformer（比如 mini-LM、cross-encoder）
2. 输入：
   • Query（用户问题 Q）
   • Candidate（某个文档块 D）
     组成一个输入：[Q] [SEP] [D]
3. 输出：
   • 一个相关度分数（0~1 或者任意实数范围）
   • 表示“这段文本 D 和问题 Q 的匹配程度”

工作流程：

1. 对 C_all 中每个候选文档块 D_i，都计算一次 score_i = f(Q, D_i)
2. 根据 score_i 降序排序
3. 选前 K 个作为最终要喂给大模型的“精选五段”

这样做的好处：

• 向量召回只做“粗筛”，速度快、范围广
• 重排模型逐个精细“理解”Q 和 D_i 的关系，准确率更高
• K 可以比较小（例如 5~20），对大模型也更友好（上下文有限）

实现步骤

离线阶段：

1. 训练或选用一个现成的 Re-ranking 模型
   • 例如开源的句子对相关性模型（MS MARCO 等数据训练的）
   • 或者自己用业务内的问答点击数据微调一个

在线阶段：

1. 得到 C_vector（向量召回 Top N）

2. 得到 C_bm25（倒排召回 Top M）

3. 合并去重得到 C_all（如 200 条以内）

4. 对 C_all 中每条候选 D_i：

   • 构造输入：[CLS] Q [SEP] D_i [SEP]
   • 喂给重排序模型
   • 得到 score_i

5. 按 score_i 排序，选前 K 条 → C_final（比如 K=8）

之后，C_final 里的每个元素都带：

• content：具体文本（段落）
• score：最终相关度分数
• source：来源文档信息（标题、URL、时间等）