RAGAS与LangSmith组合：RAG评估的完整实践指南

RAGAS 和 LangSmith 的组合，现在基本是评估 RAG 系统绕不开的一套实践方案。我自己在几个项目里把这两样东西串起来用之后，最大的感受是：评估这件事终于从“拍脑袋看几个例子”变成了“每次改动都有数据说话”。这篇文章就把我实际落地这套组合的经验完整拆开讲，包括 RAGAS 的指标逻辑、LangSmith 负责的工程环节、它们怎么串成一条可重复的评估链路，以及我在过程中踩过的坑和现在仍在沿用的配置。

1. RAG 评估为什么这么难

1.1 一条检索问答链路，问题可能出在四个地方

做 RAG 的人应该都有过这种经历：同一个问题，换一个文档库、调一下 chunk 大小、改一下 prompt 模板，回答质量就变了，但你不一定清楚变化来自哪个环节。

一条典型的 RAG 链路，从用户提问到最终回答，中间至少经历了四段：文档切分和向量化、检索召回、重排或上下文截断、再把上下文交给大模型生成回答。这四段任何一个出问题，都会以不同方式影响最终答案。比如说，文档切分粒度太粗，关键内容被埋在无关段落里，召回可能仍然能捞回来，但大模型生成的回答会显得“不聚焦”；向量模型和问题语义不匹配，召回的上下文干脆就是错的，问题就开始放飞；prompt 没有说清楚“只能依据上下文回答”，模型一旦脑补，回答看起来流畅，实际已经偏离原文。

我在项目里遇到过最典型的情况是：单独测生成模型，感觉答得很好；单独看检索召回，Top 3 也还算相关；但把整条链路串起来一测，答案就是不理想。原因往往是各个子环节自己看起来没问题，组合之后互相放大问题。比如上下文被截断了最关键的几行，或者噪声段落被塞进 prompt 后干扰了模型判断。这种“系统性故障”用人工抽查几轮很难定位，因为故障不在单一模块里，而是分布在链路复杂度中。

这也是 RAG 评估和普通模型评估最大的区别。普通 NLG 评测只需要考虑“模型是否存在幻觉、是否答非所问”，RAG 评测则必须同时覆盖检索质量和生成质量，还得能区分这两个因素各自的影响。如果你不能在指标层把它们分开，出了问题就只能靠猜。

1.2 拿“标准答案”比对，为什么在 RAG 上行不通

很多人上来第一反应是：我准备一批标准问答对，让系统回答，然后用字符相似度、BLEU、ROUGE 之类的指标跟标准答案比，不就行了吗？这个思路对纯阅读理解任务有一定参考性，但在真实 RAG 场景里非常失灵。

原因是多方面的。第一，RAG 的知识源会持续更新，文档库一变，标准答案本身就过时了，维护成本极高。第二，同一条信息可以有很多种合法表达方式，字面差异大并不代表语义错误；BLEU 和 ROUGE 这类指标对字面重合度的依赖比较大，很容易把“意思对但表达不一样”的回答误判成坏答案。第三，也是最关键的，标准答案只告诉你“最终回答对不对”，完全无法告诉你“如果回答错了，错在检索还是生成”。这就像考试只给总分，不给你每个科目的得分，你想查漏补缺都不知道该复习哪一科。

所以 RAG 评估需要的是另一套思路：不把“标准答案完全一致”当作唯一正确性来源，而是把“回答是否忠于给定的上下文、是否真正回应问题、检索到的上下文是否与问题相关”这几个维度拆开来看。这就是 RAGAS 这类评估框架诞生的基础逻辑。

2. RAGAS 到底在评什么：指标框架拆解

2.1 三个基础指标：忠实度、答案相关性、上下文相关性

RAGAS 最初落地时最常用的三个指标，正好对应上面说的三个关键问题：faithfulness（忠实度）、answer relevancy（答案相关性）、context relevancy（上下文相关性）。我分别讲一下它们的实际含义和评测逻辑，因为理解了这三个指标，后面看 LangSmith 配合跑分才有意义。

忠实度衡量的是“回答是否严格基于提供的上下文”，不要求回答必须覆盖上下文里的所有信息，但回答里不能出现上下文里没有的内容。换句话说，它抓的是幻觉问题。一个典型场景是：上下文里明明只说了产品支持三种协议，模型却在回答里补了第四种，哪怕补的内容本身是常识，在严格评估里也属于不忠实。RAGAS 的实现思路是先把回答拆成若干独立陈述句，然后逐个判断这些陈述能否从给定上下文中推导出来，最后计算被支持陈述的比例。

答案相关性衡量的是“回答到底有没有解决用户的问题”。这个指标容易和忠实度混淆，我举个反例就清楚了。用户问“这个接口的超时时间怎么设置”，模型回答“接口支持设置超时时间，具体见文档”——这句话可能完全忠于上下文，没有任何幻觉，但它没有给出设置方法和参数，答案相关性就很低。RAGAS 的评估逻辑是让评判模型根据回答反推它可能回答的问题，再计算这些推断出来的问题和原问题之间的语义相似度。

上下文相关性衡量的是“检索回来的上下文和用户问题有多相关”。这个指标直接作用在检索环节，可以在生成之前暴露出召回质量的问题。比如用户问“退款周期是多久”，召回的第一条文档是关于“售后联系方式”的，后三条才提到退款，那么上下文里真正切题的内容占比不高，这个指标就会把问题暴露出来。

这三个指标的分数范围通常都在 0 到 1 之间，越接近 1 越好。我平时看报告时会先看这三个数的轮廓：上下相关性和忠实度都高、答案相关性低，那问题大概率在生成阶段——模型没有真正回应用户意图；上下相关性低，那不管生成端分数多好看，都得先回去调检索。

2.2 扩展指标：把检索环节的问题单独挖出来

基础三个指标解决的是“这条链路整体健不健康”，但如果想进一步定位是“该召回的内容没召回”还是“召回了但混进太多噪音”，基础指标就有点不够用了。RAGAS 提供了不少扩展指标，我在实际项目里经常用的几个包括 context recall、context precision、noise sensitivity 和 answer completeness。

context recall 需要有 ground truth 参考答案参与，它评估的是“给定标准答案所涉及的事实，有多少能从检索上下文中找到”。如果这个分数低，说明检索根本没有把关键事实捞回来，后续再怎么调 prompt 都很难救回来。context precision 则不看标准答案，它关注的是“检索出来的每一条上下文，是否对最终回答有贡献”。这个指标对于定位“召回结果里是不是混了太多不相关段落”很有帮助，噪音越多，precision 就越低。

noise sensitivity 是我个人比较喜欢的一个指标，它衡量回答对上下文噪声的抵抗能力。有些模型在上下文干净时表现很好，但一旦上下文中混入几条无关内容，就会开始胡说。对于真实生产环境来说，检索结果不可能永远那么干净，这个指标能帮你提前判断当前模型对噪声有多敏感。answer completeness 则是判断回答是否完整覆盖了问题的全部需求，适合客服、售后这类对信息完整性要求高的场景。

我的使用习惯是：基础三个指标作为每次回归的固定项，扩展指标根据业务场景按需开启。每次全量跑会很费 token，后面我会专门讲成本控制，这里先记住一点——指标不是越多越好，每多加一个指标，评估耗时和成本都会非线性上涨。

2.3 LLM-as-Judge 是怎么工作的，选型要注意什么

RAGAS 自己并不拥有一个“评分模型”，它的底层仍然是让一个评判大模型来给回答和上下文打分，这就是所谓的 LLM-as-Judge。RAGAS 做的事情，是把这种评判过程结构化：把回答拆成多个陈述句、构造判断提示词、收集评判模型的判断结果、聚合成最终指标分数。

因为底层依赖 LLM 来判断，所以评判模型的选择会直接影响所有指标的数值表现。同一个 RAG 链路，用不同评判模型跑出来的分数基准完全不同，甚至可能发生“换个评判模型，结论就反转”的情况。这不是 RAGAS 特有现象，任何 LLM-as-Judge 都有这个问题。

实际操作中我有几个固定做法。第一，评判模型要和被测模型分开，不然等于让选手自己给自己打分，公正性会打折扣。第二，固定一个评判模型之后不要频繁更换，否则横向对比历史数据时，你不知道分数变化是链路改动引起的还是评判标准漂移了。第三，评判模型的温度一般设置为 0，并关闭采样随机性，保证同样的输入尽量得到同样判断。第四，如果项目对成本敏感，可以优先尝试用能力足够的中小参数模型当评判，但需要先用一批人工标注样例校验一下它和强评判模型的一致性。

3. LangSmith 补上工程化的那一块

3.1 从“离线跑一次”到“每次提交自动回归”

RAGAS 提供了相对完整的指标定义和计算逻辑，但从工程角度来看，它还缺了不少东西：数据集放哪里、跑批任务的入口怎么组织、结果如何存储和可视化、如何接入已有的 CI 流程。这些恰好是 LangSmith 擅长的领域。

我对 LangSmith 定位的理解是“评估流程的工程基座”。你可以用它管理数据集，上传一批问题，作为评估集；可以配置评估器，把 RAGAS 的指标包装成 LangSmith 能调用的 evaluator；可以通过 SDK 或 CLI 跑一轮批量评估，最后在后台看到每一轮的分数趋势。更关键的是，你可以把评估和代码提交绑定起来，每次改动都自动在固定的评估集上跑一遍，分数一旦低于阈值，流程直接标红。

这个能力对 RAG 项目的重要性，比很多人想象中大。RAG 系统迭代非常频繁：换 embedding、换重排、调 prompt、改 chunk 策略，几乎每一周都有改动。如果没有一套自动回归机制，很容易出现“这次改动解决了 A 问题，但把 B 问题搞坏了，而你过了两周才发现”。LangSmith 的价值不在于它能算出多么精妙的指标，而在于它把“算指标”这件事变成了可重复、可追溯、可持续的过程。

3.2 一条链路从输入到输出都有迹可循

LangSmith 还有另外一个让人很舒服的能力：链路追踪。每一次请求从进入系统开始，检索、拼接 prompt、调用大模型、输出回答，整个链路里的每一步输入输出都会被记录。这在调试评估结果时几乎是刚需。

举个例子：某轮评估中，faithfulness 分突然下滑。如果只有分数，你只能干瞪眼。但在 LangSmith 的 trace 里，你可以直接点进那个低分样本，看到这一轮检索返回了哪些段落、prompt 里拼接成什么样、模型输出的原始回答是什么。然后你一眼就能判断出，是检索召回的内容不理想，还是 prompt 拼接时被截断了，还是模型生成了上下文之外的内容。这种从“分数异常”到“根因定位”的下钻能力，能让定位问题的耗时从小时级压缩到分钟级。

所以 LangSmith 有点像一个带体检报告的病历系统——RAGAS 帮你算出各项指标数值，LangSmith 帮你把每个数值背后的原始证据链存下来。只看分数容易误诊，结合 trace 看才能判断要不要干预、干预哪个环节。

3.3 两个工具在评估链路里的分工

有人会问：LangSmith 自己也有 LLM-as-judge 评估器，为什么不直接用它的，还要叠一个 RAGAS？这个问题的答案在于评估粒度。

LangSmith 自带评估器偏向通用场景，比如“答案是否相等”“回答是否包含某个关键词”“是否遵循了某种指令”，这些适合作为轻量检查项。而 RAGAS 的指标是专门围绕 RAG 链路结构设计的，它对上下文、回答、问题三者之间的关系做了精细建模，比如把回答拆成原子陈述再和上下文逐条核对，这种结构化程度是通用评估器难以直接替代的。

所以我实际使用时的分工是：RAGAS 负责定义“评什么”，LangSmith 负责“怎么跑、怎么存、怎么看、怎么卡流程”。RAGAS 算出的各项指标通过接口逐项写入 LangSmith 的评估结果，之后的数据集管理、批量跑分、趋势报告、CI 回归全部交给 LangSmith。两者不是竞争关系，而是“指标设计”和“工程平台”的组合，这也是这套方案现在被大家当作主流实践的原因。

4. 把 RAGAS 与 LangSmith 组合起来的实操方案

4.1 评估数据集的准备要点

整个组合里，我最想强调的不是代码怎么写，而是数据集怎么准备。数据集的质检，直接决定评估结果的可信度，这一步没做好，后面所有的花哨操作都是空中楼阁。我通常会准备至少 20 到 30 条真实用户问题作为起步评估集，太少了分数波动剧烈，跑出来的回归结果没有统计意义。

数据集需要包含几个关键字段：question 是用户问题，answer 是对应本轮链路生成的回答，contexts 是检索返回的上下文列表，ground_truth 是人工整理的标准答案。其中 answer 和 contexts 可以通过链路运行自动收集，question 和 ground_truth 需要人工投入。

关于 ground_truth，我想多说一句：不是所有指标都需要它，比如 faithfulness、answer relevancy、context relevancy 都不依赖 ground_truth。但如果你的场景里文档是相对稳定的，我强烈建议维护一个带 ground_truth 的子集。原因不仅仅是能跑 context recall 这类指标，更重要的是人工写标准答案的过程本身就是一次对业务需求的梳理，能帮你发现很多产品定义层面的模糊地带。

LangSmith 导入数据集时，可以直接用 SDK 在线创建，也可以上传 CSV、JSONL 文件。我在项目里常用的是 CSV 方式，一列 question、一列 ground_truth，方便维护。answer 和 contexts 这种需要链路运行才能生成的数据，通常不预先放在数据集里，而是在评估时从 trace 运行结果里取，所以我们后面讲评估脚本时会看到数据集和实际执行样本的拼接方式。

4.2 编写评估脚本的完整思路

先说一个版本提醒：RAGAS 的接口迭代比较快，不同小版本之间参数名可能有差异，下面的代码示例我以 0.1.x 和 0.2.x 阶段比较常见的写法为基准，你实际使用时要对应自己装的版本号微调。

第一种组合方式，适合快速验证：先用 RAGAS 在本地数据集上跑一轮离线评估，然后把结果写入 LangSmith。核心逻辑是这样：

python复制import os
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_relevancy

os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "你的_key"
os.environ["LANGCHAIN_PROJECT"] = "rag-eval-project"

data = {
    "question": ["退款周期是多久", "这个接口支持并发吗"],
    "answer": ["退款一般在3个工作日内到账", "接口支持并发调用"],
    "contexts": [
        ["退款政策：用户申请退款后3个工作日内原路退回"],
        ["API 说明：本接口支持并发请求，上限为50"]
    ],
    "ground_truth": ["退款周期为3个工作日", "接口支持并发"]
}

dataset = Dataset.from_dict(data)
result = evaluate(dataset, metrics=[faithfulness, answer_relevancy, context_relevancy])
df = result.to_pandas()
print(df)

跑完之后，df 里每一行对应一条样本的三个指标得分。然后你可以用 LangSmith 的上传接口把结果关联到对应的 trace 或者数据集上。这种方式的优点是简单、不容易被 LangSmith 的评估器签名卡住，缺点是评估和链路执行是断开的，自动化程度不高。

第二种组合方式，是让 LangSmith 直接调用 RAGAS 的评估器，这也是我更推荐的长线方案。LangSmith 的评估流程会为每条样本生成一个 root_run 对象，我们写一个自定义评估函数，从 root_run 里取出链路输出，再转成 RAGAS 需要的 Dataset 格式，最后调 RAGAS 计算指标。大致长这样：

python复制from langsmith import evaluate as ls_evaluate
from langsmith.schemas import Example, Run

def ragas_evaluator(root_run: Run, example: Example) -> dict:
    from datasets import Dataset
    from ragas import evaluate
    from ragas.metrics import faithfulness, answer_relevancy, context_relevancy

    question = example.inputs["question"]
    answer = root_run.outputs.get("answer", "")
    contexts = root_run.outputs.get("contexts", [])

    dataset = Dataset.from_dict({
        "question": [question],
        "answer": [answer],
        "contexts": [contexts],
    })

    result = evaluate(
        dataset,
        metrics=[faithfulness, answer_relevancy, context_relevancy],
    )
    df = result.to_pandas()
    row = df.iloc[0]
    return {
        "faithfulness": row["faithfulness"],
        "answer_relevancy": row["answer_relevancy"],
        "context_relevancy": row["context_relevancy"],
    }

results = ls_evaluate(
    ragas_evaluator,
    data="你的数据集名称",
)

这个写法的关键在于理解两条数据来源：example 里存的是你预先准备的问题和标准答案，root_run 里存的是本次系统运行产生的输出。LangSmith 负责把每条样本对应的 run 和 example 配对传入，你在评估函数里手动组装出 RAGAS 需要的样本结构，再把计算出的指标以字典形式返回。LangSmith 会把返回的每个键当成独立评估指标记录到后台。

4.3 指标阈值怎么定，报告怎么看

评估跑完之后，最常被问到的就是：分数要到多少才算合格？我的回答是：没有绝对标准，但你可以建立自己的基准线。

第一次上线评估时，先别急着定阈值，把当前线上系统的分数跑出来作为基准。后面每次改动，重点看的不是绝对分数，而是相对基准的变化方向和幅度。比如忠实度从 0.85 掉到 0.78，即便 0.78 看起来还是“及格”水平，这个变化本身就是一个危险信号，说明最近的改动影响了生成事实性。

定阈值时我会分两档：硬性阈值和观察阈值。硬性阈值是底线，比如忠实度低于 0.75 时评估流程直接失败，这在 CI 里用来卡变更；观察阈值是敏感线，比如相比上次运行下降超过 0.05 就发告警，但不阻断流程，而是提醒人工介入分析。这样既避免因为微小波动频繁卡发布，又能尽早发现趋势性劣化。

看报告时我习惯按照“整体均值 -> 单条样本分布 -> 失败样本下钻”的顺序来。整体均值告诉你链路健康度变化，单条样本分布能发现是否有一类问题被平均值掩盖，失败样本下钻则用 LangSmith 的 trace 定位根因。如果多条样本都集中在某个业务板块表现差，那很可能不是模型问题，而是文档库里这块内容本身质量不行，需要回去补文档。

4.4 接入 CI 的推荐做法

把评估接入 CI 是这个方案最舒服的环节之一。LangSmith 提供了命令行工具和 Python SDK 两种启动评估的方式，我比较推荐在 CI 里用命令行触发，因为配置简单、日志干净，不依赖 Python 环境里额外维护 SDK 调用逻辑。

推荐的最小化做法是：不阻塞所有 PR，只在 main 分支合并前跑全量回归，或者在 nightly 定时任务里跑。一开始就把评估挂在每个 PR 上，会因为评估耗时和 token 成本让团队崩溃。我先从 nightly 跑起，等数据集规模稳定、评估耗时可控之后，再逐步把关键分支的回归前置到合并前检查。

CI 脚本里设置环境变量时，注意不要把 key 明文写在仓库里，用 CI 平台的 secret 管理功能。流程大致是：拉代码 -> 构建服务 -> 启动或复用已部署环境 -> 运行 LangSmith 评估命令 -> 检查退出码。LangSmith 支持设定评估结果是否通过的标准，CI 根据退出码决定本次变更是否被放行。

5. 常见问题与排查要点

5.1 线上分数波动大，是评测体系不稳还是模型随机

我最初跑评估时遇到的最头疼问题，就是同一套代码、同一个评估集，连续跑两次，分数能差出 0.1。排查之后发现原因通常是三个方面：评判模型本身有随机性、测试集样本量太小、数据分布太集中。

解决办法也是围绕这三方面展开。评判模型必须设置 temperature 为 0；测试集尽量扩充到 30 条以上；数据分布要有一定覆盖面，不能全是同类型问题。如果做了这些分数还是抖，那就采用多次运行取平均，把评估跑两次或三次，用均值作为报告分数。虽然成本增加，但换来的稳定性在回归对比场景里是值得的。

另一个容易忽略的点是：模型服务的负载会影响评估结果。如果被测模型在评估期间因为高并发被限流或退化，回答质量会下降，分数会被带偏。所以评估最好在服务负载较稳定的窗口执行，并且保证被测模型使用独立配额。

5.2 Token 成本过高，跑一次评估很肉疼

RAGAS 的多指标评估本质上是多次 LLM 调用，而且每个指标都可能调用不止一次评判模型。比如 faithfulness 要把回答拆成若干陈述，再逐条判断支持性；answer relevancy 要让模型反推问题再算相似度。一个 30 条的测试集，跑完 6 个指标，一天配额烧掉一大部分是完全可能的。

成本控制上我的经验是：先跑最少必要指标集。日常回归只跑三个基础指标，扩展指标单独安排在低频专项评估里。测试集也可以分层：核心精标集 20 到 30 条用于高频回归，大样本集 100 条以上用于每周或版本发布前的完整评估。评估如果只是看趋势，不需要每次都全量跑。

还有一个可行的方案是把评判模型从高端模型降级到能力尚可但便宜得多的中小模型。这个操作需要先做一个“评判一致性校验”，拿 20 条人工标注样本，比较两种评判模型的结论是否一致，一致率超过 90% 再切换。我试过几次之后发现，只要业务场景不是特别专业，中小模型的判断结果基本可信，成本能降一个数量级。

5.3 数据集格式不一致导致的低级报错

RAGAS 和 LangSmith 对数据格式的隐式要求不少，踩坑最多的就是字段类型和命名。

RAGAS 要求 contexts 是列表的列表，也就是每条样本的 context 是一个字符串列表，即使只有一条上下文也要放在列表里。如果拿单个字符串往里去，看起来没报错但实际上评分结果非常离谱。answer 列在离线评估时必须存在，如果用 LangSmith 在线评估方式，要在评估函数里明确从 root_run 取出来，否则会得到空字符串集导致指标无效。

LangSmith 上传 CSV 时列名也有讲究，默认情况下列名会原样保留，但如果你在代码里用了不同字段名，比如到处用 “query” 而数据集里是 “question”，那评估脚本里访问 example.inputs 时就会 KeyError。我现在的做法是：数据集的字段命名固定为 question、answer、contexts、ground_truth 四个，任何代码都遵循这个约定，避免在脚本里做过多映射，映射一多就容易出 bug。

5.4 评估器配置的典型坑

LangSmith 自定义评估器看起来简单，但有几个细节很容易埋雷。第一个是评估函数的签名，LangSmith 会传入两个参数，类型分别是 Run 和 Example，两个参数的顺序别写反，不然运行时拿到的数据完全不对，而且不报错，只是结果诡异。第二个是返回值，必须是一个可序列化的字典，键名对应指标名，值是 int 或 float；有人直接把 RAGAS 的 entire result 对象返回，LangSmith 记录不到任何分数。第三个是注入 RAGAS 的评估器版本兼容问题，尤其是新版 RAGAS 里 evaluate 函数对输入格式的要求变了，在线评估脚本里出现的报错往往和版本强相关。

我的建议是：在线评估函数先拿单条样本 debug 通过，再挂到 LangSmith 上跑全量。具体做法是在本地直接构造一个 Run 和 Example 的模拟对象，调用评估函数断言输出字典符合预期。这个步骤能省掉后面排查环境集成问题的大量时间。

6. 关于这个组合，我的几个经验判断

6.1 先把最小闭环跑通，再谈大而全

如果你现在正准备给 RAG 项目搭建评估体系，我最大的建议是别一上来就把所有指标、所有流程都配齐。第一次可以只准备 15 到 20 条数据，只跑一个 faithfulness 指标，用最简单的离线脚本把 RAGAS 跑通，再手动把结果贴到 LangSmith 里看趋势。等这个最小闭环稳定之后，再加 answer relevancy、context relevancy，再把评估函数整个嵌进 LangSmith，最后才接入 CI。

我见过不少团队在评估这件事上死于过重配置：数据集几百条、指标开了七八个、CI 里全量跑，结果每次评估要跑几十分钟、烧掉大量 token，团队很快就失去耐心。评估体系的建设是渐进式的，它最终的形态一定是在“可信度”和“成本可承受”之间找到平衡，而这个平衡只能靠你自己的数据慢慢试出来。

6.2 评估链路和业务链路一样需要持续维护

最后分享一个容易被忽略的点：RAGAS 和 LangSmith 这套组合本身不是一次搭完就一劳永逸的基建，它需要像业务链路一样持续维护。数据集要随着业务变更增删样本，旧文档删了、新功能上线，评估集里对应的用例要跟着更新；指标阈值会因为模型升级或文档库变化而失去参考价值，需要定期重新校准；评判模型如果厂商升级了版本，它的打分倾向可能悄悄变了，历史分数的可比性会受到挑战。

我个人的习惯是每个月留出固定时间专门做评估体系维护：更新一批数据集、复跑一次基准、检查上个月的分数趋势和 trace 里暴露的异常模式。这套组合真正发挥威力，靠的不是某一次完美配置，而是长期稳定的持续迭代——评估体系本身也需要用迭代的眼光去看待。