AI搜索核心指标（准确率/延迟/成本）

可视化演示

演示AI搜索在准确率、首字延迟与token成本三个核心维度间的动态平衡，展示不同模型规模与预算下的SLA设计权衡。

三大维度平衡

阿乐的餐厅刚开张时，他只想把菜做到极致：高薪挖来名厨，所有食材空运进口，一道菜雕花雕半小时。结果一个月下来，顾客没等来几个——菜太贵、上菜太慢，虽然味道一绝，但没人愿意为一份红烧肉等四十分钟。他这才明白，开餐厅不是做艺术品，得在“好吃、快、便宜”这三个维度里找平衡。

AI搜索产品也一样。评价一个AI搜索系统，业界公认三个核心维度：准确率（回答是否靠谱）、延迟（响应是否迅速）、成本（一次搜索要消耗多少算力和Token）。三个维度像三根绷紧的皮筋，拉紧任何一根，另外两根都会跟着变形。准确率想从 80% 提到 90%，可能就要换更大的模型，延迟和成本双双上涨；想压缩延迟，就得简化流程，答案质量可能打折。产品团队每天都在做这种“按下葫芦浮起瓢”的取舍决策。

阿乐后来重新设计了菜单：招牌菜保留精致做法，但增加了三十块钱以内的快手菜，翻台率上去了，回头客也变多了。他渐渐明白，开餐厅和做搜索产品的道理是通的——没有最好的指标，只有最合适的平衡。

准确率评估

阿乐想搞清楚自家菜到底水平如何，于是雇了一队“神秘食客”：他们装扮成普通顾客，点菜、品尝、然后按统一的评分表打分。神秘食客和真实顾客的评分高度一致，成了餐厅质量评估的可靠来源。有了这支队伍，阿乐再也不用靠“感觉”判断菜品好坏。

AI搜索产品的准确率评估，思路惊人地相似。传统做法是把答案和标准答案人工比对，费时费力且难以规模化。现在业界通行 LLM-as-Judge（大模型当裁判）方法：让一个大语言模型扮演神秘食客，输入“问题 + 候选答案 + 参考答案”，让裁判模型按 1 到 5 分给候选答案打分，最后汇总成准确率。评估用的样本集由真实用户问题构成，覆盖越广、质量越高，评估结果就越可信。

阿乐发现，神秘食客团的质量直接决定评估的可靠性——如果某个食客爱吃辣就偏袒辣菜，评分就失真了。AI搜索也一样，裁判模型自身的能力和公正性，决定了整个准确率评估体系的可信度。

延迟优化

顾客在餐厅坐下后，心里其实有两个计时器：一个是“第一道菜多久端上来”，另一个是“整桌菜多久上齐”。前者决定顾客的第一印象，后者决定用餐总时长。阿乐发现，哪怕第一道菜只是碟酸辣土豆丝，只要上得快，顾客的耐心就会成倍增加。

AI搜索的延迟同样拆成两个计时器。首字延迟（TTFT，Time To First Token）指用户发出请求到收到第一个输出 token 的时间，它决定了用户有没有“即时反馈感”；端到端延迟指从发请求到完整答案展示完的时间。为了掩藏等待，几乎所有 AI 搜索产品都使用流式输出——像打字机一样一个字一个字往外吐，用户感觉系统在“边想边说”，而不是干等。

阿乐后来规定，客人落座五分钟内必须先上一道开胃小菜，哪怕是免费的——顾客手里有东西吃，等多久都不慌。AI搜索产品做流式输出，就是那道开胃小菜。首字延迟优化的目标，就是让“开胃小菜”尽早端上桌。

成本控制

阿乐做过一个疯狂实验：把餐厅所有菜品换成和牛、松露、鱼子酱。味道确实轰动全城，但月底一算账，收入还不够买食材的零头。他这才悟出一个道理——“顶配”不等于“高利润”，食材成本和菜品定价之间必须有个经济性平衡。

AI搜索的成本大头在 Token 消耗。每次搜索，用户的问题、检索到的上下文、模型生成的答案，都要按 token 计费。输入 token 和输出 token 的单价不同，通常输出更贵。此外，模型的参数量直接决定调用的基础价格——大模型推理成本高，小模型相对便宜。所以 AI 产品团队常做“路由”：简单问题派给便宜小模型，复杂问题才交给旗舰大模型，配合缓存把高频问题的答案存起来复用，让每次搜索的边际成本趋近于零。

阿乐后来给菜单分了两条线：平价的日常菜走量，高端食材只做限时限量的主厨推荐。顾客各取所需，成本也稳住了。AI搜索的“路由”策略，本质就是给菜单分线。

SLA设计

阿乐在餐厅门口挂了块牌子：“我们承诺，点单后30分钟内上齐所有菜，超时整单打八折。”这就是一个 SLA。它不是口号，而是可以被量化验证的服务承诺——承诺什么、怎么测量、不达标怎么办，全部写清楚。

AI搜索产品的 SLA 同样是把模糊的期望翻译成可量化的技术指标。SLA（服务等级协议）是服务方和用户之间的契约；SLI（服务等级指标）是具体怎么量测，比如 P95 延迟（95% 的请求延迟小于某个值）；SLO（服务等级目标）是承诺的达标线，比如“P95 首字延迟不超过 1.5 秒”。SLA 设计的关键是给延迟设定预算：从用户浏览器到 API 网关、再到模型推理，每一跳都要分配时间额度，超预算的环节做降级处理——比如高峰期退化为缓存答案或精简检索。

阿乐发现，挂出承诺牌后客人明显更放心，但他也再不敢让后厨出现“菜做不出来”的尴尬。SLA 不是面子工程，它是倒逼整个系统做预算、做冗余、做兜底的那只手。

产品决策

阿乐后来发现，每家餐厅的活法都不一样。快餐店拼的是快和便宜，米其林餐厅拼的是极致体验，私房菜馆拼的是稀缺与精准。没有放之四海而皆准的经营公式，只有适合自己的定位。

AI搜索产品也一样。做电商导购搜索，用户要的是“快”和“便宜”，延迟不行用户立刻跳走；做法律或医疗垂直搜索，用户要的是“准”，宁可多等几秒、多花点钱，也必须给正确且可溯源的答案；做企业内部的轻量级知识库搜索，成本则往往是最敏感的。产品团队需要根据场景把三个指标排出优先级，把有限的资源投到最影响体验的维度上。

阿乐最终把餐厅定位成“附近上班族的工作食堂”：上菜快、价格公道、招牌菜有水平。定位明确后，很多决策都不纠结了。AI搜索产品想清楚用户是谁、要什么，三个指标的优先级自然就有了。

AI 应用场景

Python 演示

#!/usr/bin/env python# -*- coding: utf-8 -*-"""模拟 LLM-as-Judge 评估 AI 搜索答案，并估算延迟与成本"""  def llm_judge(answer, reference):    """模拟裁判模型对答案打分（1-5分）"""    hits = sum(1 for kw in reference["keywords"] if kw in answer)    return min(5, 1 + hits)  def evaluate(answers, references):    total = 0    for idx, (ans, ref) in enumerate(zip(answers, references), 1):        score = llm_judge(ans, ref)        total += score        print("样本%d: %s" % (idx, ref["question"]))        print("  答案: %s" % ans)        print("  裁判打分: %d/5" % score)    return total / (5.0 * len(answers)) * 100  def estimate_latency(ttft, tokens, speed):    return ttft + tokens / speed  def estimate_cost(input_tokens, output_tokens, pin, pout):    return input_tokens * pin + output_tokens * pout  def main():    references = [        {"question": "什么是 Transformer 的核心机制？",         "keywords": ["注意力", "编码器", "解码器"]},        {"question": "什么是 RAG 检索增强生成？",         "keywords": ["检索", "生成", "外部知识库"]}    ]    answers = [        "Transformer 的核心是多头注意力机制，整体由编码器和解码器堆叠而成。",        "RAG 结合外部知识库进行检索，再把检索结果交给模型生成答案。"    ]    acc = evaluate(answers, references)    print("准确率: %.1f%%" % acc)     latency = estimate_latency(0.6, 300, 25)    cost = estimate_cost(200, 300, 0.003, 0.03)    print("端到端延迟估计: %.2f 秒" % latency)    print("单次成本估计: $%.4f" % cost)  if __name__ == "__main__":    main()

1. def llm_judge(answer, reference):模拟裁判打分，输入候选答案和参考答案
2. hits = sum(1 for kw in reference["keywords"] if kw in answer)统计答案里命中多少个关键词
3. return min(5, 1 + hits)1 分保底，命中越多分越高，封顶 5 分
4. return total / (5.0 * len(answers)) * 100平均分除以 5 再乘 100，转成百分制准确率
5. def estimate_latency(ttft, tokens, speed):按首字延迟加生成时间估算端到端延迟
6. def estimate_cost(input_tokens, output_tokens, pin, pout):按输入输出 token 单价计算成本
7. if __name__ == "__main__":保证脚本作为入口执行，而不是被当作模块导入

常见误区

面试题