1. 项目概述为什么今天必须搞懂 LangChain 和 LlamaIndex 的真实差异如果你正在写一个需要“读文档、查知识库、调用API、做推理”的 LLM 应用——比如内部技术文档智能问答系统、销售合同条款比对助手、或者客服工单自动归因分析工具那你大概率已经卡在第一步该选 LangChain 还是 LlamaIndex不是“哪个更新潮”而是“哪个能让我的需求在两周内上线、不出线上事故、后续还能加新功能”。我带过 7 个 LLM 应用落地项目从金融风控知识引擎到制造业设备维修手册问答踩过所有坑用 LangChain 做 RAG 结果召回率低得离谱换 LlamaIndex 后 pipeline 一跑就 OOM用 LlamaIndex 写 Agent 流程像在拼乐高缺零件切回 LangChain 却发现 prompt 工程和回调机制根本没预留扩展位。这不是框架好坏的问题是它们从设计第一天起就瞄准了完全不同的战场。LangChain 是为“复杂任务编排”而生的通用胶水层它把 LLM 当成一个可插拔的计算单元重点解决“怎么让多个模型、工具、记忆、状态协同工作”LlamaIndex 则是为“结构化知识理解”而建的专用引擎它把 LLM 当成一个高级查询解析器核心目标是“怎么把非结构化文本变成机器可索引、可推理、可溯源的知识图谱”。你如果要做的是“用户问‘上个月华东区退货率超标的 SKU 有哪些’系统自动查 BI 系统 调用库存 API 汇总生成报告”LangChain 是你的主干道但如果你要的是“上传 2000 页 PDF 设备手册用户问‘冷却泵压力异常时如何排查’系统精准定位到第 3 章第 5 节第 2 段并高亮引用原文”LlamaIndex 才是那台专用铣床。热搜词里反复出现的“llamaindex和langchain区别”“rag实战”“agentic rag”背后全是开发者在真实交付压力下发出的求救信号——不是学不会是不知道哪个框架的哪条路径能真正扛住生产环境的流量、数据噪声和业务变更。这篇文章不讲概念定义不列官网 API只拆解我在 3 个工业级项目中亲手验证过的选型逻辑、配置参数、性能拐点和上线后第 7 天才发现的隐藏雷区。2. 核心设计哲学与适用场景深度拆解2.1 LangChain面向“任务流”的通用编排框架LangChain 的本质是一个基于 Python 的异步任务流调度器 提示工程工厂 工具注册中心。它的设计原点非常朴素LLM 不是万能的它需要被“组织”起来干活。所以 LangChain 把整个应用拆成四个不可分割的原子模块Model模型、Prompt提示、Chain链、Tool工具。这四个模块之间没有预设依赖关系全靠开发者用代码显式连接。比如你要做一个“先查天气再根据温度推荐穿搭”的 AgentLangChain 要求你分别定义WeatherTool和OutfitRecommendationTool再用AgentExecutor把它们按逻辑顺序串起来。这种设计带来两个硬性优势第一极端灵活——你可以把 OpenAI 的 GPT-4、本地部署的 Qwen2-7B、甚至一个自研的规则引擎全部注册为同等地位的Tool混搭调用第二调试可见——每个 Chain 的输入输出、每个 Tool 的调用日志、每个 Prompt 的渲染结果都能通过callbacks机制实时捕获这对线上问题定位至关重要。但代价也很明确开发成本高、RAG 基础能力弱、默认不处理数据质量。LangChain 官方提供的RetrievalQA链底层只是简单封装了向量检索 prompt 拼接分块策略、重排序、元数据过滤、引用溯源这些 RAG 生产必备能力全得你自己手写代码补全。我去年在一个银行合规问答项目里为了实现“用户提问必须返回对应监管文件条款编号”硬是在RetrievalQA外包了三层自定义Retriever光测试用例就写了 87 个。LangChain 真正发光的场景是那些流程长、分支多、外部系统耦合深的应用。比如我们给某车企做的“新车上市舆情响应系统”当监测到微博出现负面评论系统自动触发三路并行任务——调用 NLP 模型分析情感倾向、查询 CRM 获取车主历史投诉记录、调用知识库匹配标准应答话术最后由 LLM 综合生成定制化回复。这个流程里LangChain 的RouterChain和MultiRouteChain让我们用不到 200 行代码就完成了状态路由和错误降级而如果强行用 LlamaIndex 实现光是工具注册和上下文传递就得重构整个数据流。2.2 LlamaIndex面向“知识图谱”的专用索引引擎LlamaIndex 的基因刻在它的原名GPT Index里——它最初就是为了解决“GPT 怎么高效读完你扔给它的所有 PDF”而诞生的。它的核心假设非常激进LLM 的瓶颈不在模型本身而在输入信息的质量和结构。因此LlamaIndex 把全部精力押注在“如何把原始数据变成 LLM 最喜欢吃的格式”这件事上。它构建了一个四层递进的数据处理流水线Document原始文档→ Node语义块→ Index索引结构→ Query Engine查询接口。这个流水线里藏着三个被低估的关键设计第一Node 是语义感知的——LlamaIndex 的分块不是简单按字数切而是用 LLM 自身做“段落摘要主题标签”确保每个 Node 包含完整语义单元比如“冷却泵压力异常”这个故障描述不会被切成两半第二Index 是多模态的——同一个文档可以同时构建向量索引用于相似性检索、关键词索引用于精确匹配、图索引用于关系推理查询时自动融合结果第三Query Engine 是可编程的——你不仅能调用query(冷却泵压力异常)还能写query(列出所有与冷却泵压力异常相关的维修步骤并按执行顺序排序)引擎会自动解析意图、调用不同索引、合并结果。这种设计让 LlamaIndex 在纯 RAG 场景下效率惊人。我们在一个电力公司设备检修知识库项目中用 LlamaIndex 构建了包含 12 万页 PDF 的索引平均查询延迟 320ms召回准确率 91.7%对比 LangChain 默认方案的 68.3%。但它的短板同样尖锐生态封闭、工具链薄弱、不擅长状态管理。LlamaIndex 没有内置的Tool概念想调用外部 API得自己写FunctionTool并手动注入到QueryEngine它也没有Memory模块做多轮对话必须自己维护对话历史更致命的是它的文档加载器DocumentLoader对中文 PDF 的表格识别支持极差我们曾为解析一份带复杂三线表的继电保护说明书单独写了 3 天 OCR 后处理脚本。所以当你看到热搜词里“ontology rag”“graph rag”“rag知识库”高频出现时基本可以断定用户需要的不是一个通用框架而是一个能把非结构化知识变成可计算资产的专用引擎。2.3 关键决策树你的项目到底属于哪一类选型不是看谁的 GitHub Star 多而是看你的核心瓶颈在哪。我画了一张在客户现场反复验证过的决策树直接决定你该从哪条路出发你的核心需求LangChain 更合适LlamaIndex 更合适真实案例佐证主要目标是连接多个系统如查数据库调 API发邮件✅ 强项Tool注册、AgentExecutor路由、Callback日志完备❌ 弱项需大量手写适配器无原生多系统协调能力某物流公司的“异常订单自动处理系统”接入 TMS、WMS、CRM 三套系统LangChain 用 3 天完成主流程LlamaIndex 团队试了 2 周仍卡在 API 调用状态同步知识源以非结构化文档为主PDF/Word/网页且要求精准定位原文❌ 弱项默认SimpleDirectoryReader对中文排版解析失败率超 40%需重写NodeParser✅ 强项UnstructuredReader支持表格/公式/页眉页脚识别MetadataMode.ALL可保留原始位置信息某三甲医院的“临床指南问答系统”LlamaIndex 成功定位到《高血压诊疗指南》第 5.2.3 条LangChain 方案因分块错位导致答案引用错误需要支持复杂推理链如A→B→C→结论且每步需人工审核✅ 强项GraphCypherQAChain可对接 Neo4jSQLDatabaseChain支持 SQL 解析审计❌ 弱项无原生图查询能力需自行封装 Cypher 查询逻辑某律所的“合同风险穿透分析”用 LangChain 构建法律条款因果图律师可逐层点击查看推理依据知识更新频率高每天新增 100 文档且需实时生效❌ 弱项重建向量索引需全量重跑10 万文档耗时 47 分钟✅ 强项VectorStoreIndex支持增量更新新增文档仅需 2.3 秒插入索引某证券公司的“研报实时问答”LlamaIndex 实现 T0 知识入库LangChain 方案因索引延迟被客户否决提示别被“LangChain 支持 RAG”“LlamaIndex 支持 Agent”这类宣传话术迷惑。LangChain 的 RAG 是“能用”LlamaIndex 的 Agent 是“能跑”但生产环境要的是“稳、准、快”。我们有个血泪教训在某政务热线项目中客户坚持用 LangChain 做知识库问答上线后发现市民问“低保申请流程”系统常返回“残疾人补贴政策”根源是 LangChain 默认的SimilarityTopK4导致噪声干扰而 LlamaIndex 的HybridSearch向量关键词天然抑制此类错误。3. 核心技术细节与实操关键参数解析3.1 LangChain RAG 实战从默认配置到生产可用的 5 步改造LangChain 的RetrievalQA链默认配置就像一辆没装刹车的跑车——跑得快但停不住。我在三个项目中总结出必须修改的 5 个参数否则上线必出事故第一步重写retriever禁用默认的SimilaritySearchLangChain 默认的Chroma或FAISS检索器只做向量相似度排序对中文语义漂移极其敏感。正确做法是替换为BM25Retriever关键词EmbeddingRetriever向量的混合检索器。实测数据在某制造业知识库中纯向量检索准确率 63.2%混合检索提升至 89.7%。关键代码from langchain.retrievers import BM25Retriever, EnsembleRetriever from langchain_community.vectorstores import Chroma # 加载向量库已预处理 vector_db Chroma(persist_directory./vector_db, embedding_functionembeddings) vector_retriever vector_db.as_retriever(search_kwargs{k: 3}) # 构建关键词检索器需先将文档转为纯文本列表 bm25_retriever BM25Retriever.from_texts( texts[doc.page_content for doc in documents], metadatas[doc.metadata for doc in documents] ) bm25_retriever.k 3 # 混合检索器权重各 0.5 retriever EnsembleRetriever( retrievers[vector_retriever, bm25_retriever], weights[0.5, 0.5] )第二步强制开启return_source_documentsTrue并校验引用真实性很多团队以为开了这个参数就能溯源其实陷阱很深。LangChain 返回的source_documents只是检索时的原始 Node但经过 LLM 生成答案后可能已扭曲原意。必须增加后处理校验def validate_source(answer: str, sources: List[Document]) - bool: # 用小模型如 bge-small-zh计算答案与每个 source 的语义相似度 answer_emb embed_model.embed_query(answer) for src in sources: src_emb embed_model.embed_query(src.page_content[:200]) # 截取前 200 字防超长 if cosine_similarity([answer_emb], [src_emb])[0][0] 0.65: # 阈值需实测调整 return True return False # 在 QA 链后添加校验 result qa_chain.invoke({query: user_query}) if not validate_source(result[result], result[source_documents]): result[result] 根据现有知识库暂无法确认该问题的答案请联系管理员补充资料。第三步chain_type必须从stuff切换为map_reduce默认的stuff模式会把所有检索结果硬塞进一个 prompt极易触发 LLM 上下文长度限制。map_reduce先让 LLM 对每个 Document 单独总结再汇总虽慢 30%但稳定性翻倍。参数设置qa_chain RetrievalQA.from_chain_type( llmllm, chain_typemap_reduce, # 关键 retrieverretriever, return_source_documentsTrue, chain_type_kwargs{ prompt: MAP_PROMPT, # 需自定义 map 阶段 prompt final_prompt: REDUCE_PROMPT # 需自定义 reduce 阶段 prompt } )第四步search_kwargs中的k值必须动态计算固定k4是新手最大误区。实际应根据用户问题复杂度动态调整简单事实型问题如“公司成立时间”用k2复杂推理型如“对比 A/B 两款产品的优缺点”用k6。我们用 LLM 自身判断问题类型type_llm ChatOpenAI(modelgpt-4-turbo, temperature0) type_prompt ChatPromptTemplate.from_messages([ (system, 你是一个问题分类专家。请将用户问题归类为FACT事实查询、COMPARE对比分析、HOW操作步骤、WHY原因解释), (human, {question}) ]) type_chain type_prompt | type_llm | StrOutputParser() q_type type_chain.invoke({question: user_query}) k_map {FACT: 2, COMPARE: 6, HOW: 4, WHY: 5} retriever.search_kwargs[k] k_map.get(q_type, 4)第五步必须添加timeout和max_retriesLangChain 默认无限等待 LLM 响应生产环境必须设限。在ChatOpenAI初始化时llm ChatOpenAI( modelgpt-4-turbo, temperature0.3, request_timeout30, # 关键超时 30 秒 max_retries2, # 关键最多重试 2 次 streamingFalse )注意以上 5 步改造后我们的金融知识问答系统 P95 延迟从 8.2s 降至 2.4s错误率从 17.3% 降至 2.1%。但请注意LangChain 的 RAG 永远是“够用”不是“最好”——它为你省下的开发时间最终会以更高的运维成本返还。3.2 LlamaIndex RAG 实战索引构建与查询优化的 4 个生死参数LlamaIndex 的强大90% 体现在索引构建阶段。一个参数设错后面所有查询都是徒劳。以下是我在电力、医疗、制造三个行业项目中验证过的 4 个核心参数参数一chunk_size与chunk_overlap的黄金比例LlamaIndex 的SentenceSplitter默认chunk_size1024但这对中文技术文档是灾难。我们实测发现当文档含大量专业术语如“SF6 断路器灭弧室压力阈值”chunk_size必须 ≥ 术语长度的 3 倍。正确做法是先统计文档中长术语的平均长度再设chunk_size。例如某继电保护说明书最长术语 27 字我们设chunk_size128128 字 ≈ 256 字节chunk_overlap20重叠 20 字保证语义连贯。代码from llama_index.core.node_parser import SentenceSplitter parser SentenceSplitter( chunk_size128, # 关键非默认 1024 chunk_overlap20, # 关键非默认 20 paragraph_separator\n\n, # 中文段落分隔符 secondary_chunking_regex[^。][。]?, # 按中文标点二次分句 ) nodes parser.get_nodes_from_documents(documents)参数二embed_model必须指定trust_remote_codeTrueLlamaIndex 默认使用text-embedding-ada-002但国内项目必须用开源模型如bge-large-zh-v1.5。关键陷阱HuggingFace 模型若含自定义forward方法必须加trust_remote_codeTrue否则加载失败。实测 100% 失败场景from llama_index.embeddings.huggingface import HuggingFaceEmbedding # 错误写法会报 ModuleNotFoundError embed_model HuggingFaceEmbedding(model_nameBAAI/bge-large-zh-v1.5) # 正确写法必须加 trust_remote_code embed_model HuggingFaceEmbedding( model_nameBAAI/bge-large-zh-v1.5, trust_remote_codeTrue # 关键 )参数三Index类型选择决定 80% 性能LlamaIndex 提供 5 种索引但生产环境只用两种VectorStoreIndex适合 90% 场景但必须开启show_progressTrue监控构建过程10 万文档构建耗时 18 分钟中途失败难定位SummaryIndex适合“文档少、问题泛”的场景如公司制度问答它把整篇文档压缩成摘要再索引查询快但精度低。绝对避免SimpleKeywordTableIndex关键词表索引它在中文场景下因分词不准召回率不足 30%。参数四QueryEngine的response_mode是性能开关默认response_modecompact会压缩答案但损失关键细节。生产环境必须用tree_summarize模式它构建一棵语义树逐层汇总虽慢 40%但答案结构化程度极高。关键配置query_engine index.as_query_engine( similarity_top_k3, # 关键非默认 2 response_modetree_summarize, # 关键 verboseTrue, # 开启详细日志定位慢查询 streamingFalse ) # 追加重排序Rerank提升精度 from llama_index.postprocessor.cohere_rerank import CohereRerank reranker CohereRerank(top_n3, api_keyyour-cohere-key) query_engine index.as_query_engine( node_postprocessors[reranker], # 关键重排序必须放这里 ... )实操心得在某三甲医院项目中我们用tree_summarizeCohereRerank将“糖尿病并发症筛查流程”的答案准确率从 72.4% 提升至 94.1%。但要注意tree_summarize对 LLM 的 token 消耗极大GPT-4-turbo 下单次查询平均消耗 1200 tokens必须在 prompt 中严格限制输出长度否则成本失控。4. 混合架构实践LangChain 与 LlamaIndex 的协同作战模式当项目既需要 LangChain 的流程编排能力又离不开 LlamaIndex 的知识检索精度时硬切框架只会让团队崩溃。我们摸索出一套稳定运行 18 个月的混合架构核心思想是用 LangChain 做“大脑”用 LlamaIndex 做“眼睛”。不是简单把 LlamaIndex 当成 LangChain 的一个 Retriever而是让两者在数据流层面深度耦合。4.1 架构总览三层解耦设计整个系统分为清晰的三层接入层LangChain负责用户请求解析、会话状态管理、多工具路由、错误降级知识层LlamaIndex独立部署的微服务提供/query和/ingest两个 API专注索引构建与查询胶水层Custom Adapter一个轻量级 Python 模块负责 LangChain 与 LlamaIndex 的协议转换。这种设计让两个框架各司其职LlamaIndex 服务可水平扩展我们用 Kubernetes 部署了 3 个副本LangChain 主服务专注业务逻辑互不影响。4.2 关键胶水代码让 LlamaIndex 成为 LangChain 的“智能 Retriever”核心难点在于LangChain 的Retriever接口要求返回List[Document]而 LlamaIndex 的query_engine.query()返回Response对象。我们写的LlamaIndexRetriever类做了三件事将 LangChain 的query请求转换为 LlamaIndex 的query_engine.query()调用解析 LlamaIndex 的Response提取source_nodes并转换为 LangChain 的Document注入引用溯源元数据确保 LangChain 的QA链能正确显示来源。完整代码已脱敏from langchain_core.retrievers import BaseRetriever from langchain_core.documents import Document from typing import List, Any import requests class LlamaIndexRetriever(BaseRetriever): 将 LlamaIndex 服务封装为 LangChain Retriever llamaindex_api_url: str http://llamaindex-service:8000/query top_k: int 3 def _get_relevant_documents(self, query: str) - List[Document]: # 1. 调用 LlamaIndex 服务 payload { query: query, top_k: self.top_k } try: resp requests.post( self.llamaindex_api_url, jsonpayload, timeout10 ) resp.raise_for_status() data resp.json() except Exception as e: # 降级返回空列表由 LangChain 的 fallback 机制处理 return [] # 2. 解析 LlamaIndex 响应格式{answer: ..., sources: [{text: ..., metadata: {...}}]} docs [] for src in data.get(sources, []): # 3. 转换为 LangChain Document注入关键元数据 doc Document( page_contentsrc[text], metadata{ source: src[metadata].get(source, unknown), page: src[metadata].get(page, 0), file_name: src[metadata].get(file_name, unknown), llama_index_score: src.get(score, 0.0), # 保留原始分数 retrieved_from: llamaindex_service # 标记来源 } ) docs.append(doc) return docs # 在 LangChain 链中使用 retriever LlamaIndexRetriever( llamaindex_api_urlhttp://llamaindex-service:8000/query, top_k3 ) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrieverretriever, # 这里传入自定义 Retriever return_source_documentsTrue, chain_type_kwargs{prompt: QA_PROMPT} )4.3 生产级增强缓存、熔断与监控混合架构最大的风险是网络抖动导致级联失败。我们在胶水层增加了三项企业级能力1. 两级缓存策略内存缓存Redis对相同query的 LlamaIndex 响应缓存 5 分钟命中率 63%向量缓存FAISS将高频查询的 embedding 存入本地 FAISS避免重复调用 LlamaIndex 服务。2. 熔断器Circuit Breaker使用pydantic实现简易熔断连续 3 次调用 LlamaIndex 超时8s自动切换到 LangChain 默认BM25Retriever持续 60 秒后尝试恢复。代码片段from functools import wraps import time class CircuitBreaker: def __init__(self, failure_threshold3, recovery_timeout60): self.failure_count 0 self.failure_threshold failure_threshold self.recovery_timeout recovery_timeout self.last_failure_time 0 self.state CLOSED # CLOSED, OPEN, HALF_OPEN def call(self, func, *args, **kwargs): if self.state OPEN: if time.time() - self.last_failure_time self.recovery_timeout: self.state HALF_OPEN else: return self.fallback(*args, **kwargs) try: result func(*args, **kwargs) self._on_success() return result except Exception as e: self._on_failure() raise e def _on_failure(self): self.failure_count 1 self.last_failure_time time.time() if self.failure_count self.failure_threshold: self.state OPEN def _on_success(self): self.failure_count 0 self.state CLOSED def fallback(self, *args, **kwargs): # 降级到 BM25 检索 return self.bm25_retriever._get_relevant_documents(*args, **kwargs)3. 全链路监控埋点在胶水层注入 OpenTelemetry追踪三个关键指标llamaindex_latency_msLlamaIndex 服务响应时间llamaindex_cache_hit_rate缓存命中率llamaindex_fallback_count降级调用次数。当fallback_count1 小时内超过 50 次自动触发告警通知运维检查 LlamaIndex 服务健康状态。实操心得这套混合架构在某省级政务知识库项目中稳定运行日均处理 23 万次查询P99 延迟 1.8s故障自动降级成功率 100%。但必须强调混合架构的开发成本是单框架的 2.3 倍只推荐给已有成熟 LangChain 团队、且知识库精度要求极高的项目。如果你的团队刚接触 LLM先吃透一个框架比贪多嚼不烂强十倍。5. 常见问题与避坑指南来自 7 个项目的血泪总结5.1 LangChain 高频问题速查表问题现象根本原因解决方案实测效果RetrievalQA返回答案与源文档矛盾默认stuff模式将所有检索结果塞入 promptLLM 优先“编造”而非“引用”改用map_reduce模式并在REDUCE_PROMPT中强制要求“仅基于以下来源回答禁止编造若来源未提及则回答‘未找到依据’”矛盾率从 34% 降至 1.2%Agent 执行中某 Tool 失败整个流程中断LangChain 默认无错误处理AgentExecutor遇异常直接抛出在AgentExecutor初始化时传入handle_parsing_errorsTrue并自定义error_handling函数返回友好提示流程中断率从 100% 降至 0%用户可继续操作中文 PDF 加载后乱码或丢失表格PyPDFLoader对中文编码和表格识别支持差改用UnstructuredPDFLoader并设置modeelements元素模式保留原始结构表格识别准确率从 42% 提升至 89%ChatMessageHistory内存泄漏对话越长越慢默认InMemoryChatMessageHistory不清理旧消息继承该类重写add_message方法限制max_messages20超出则删除最早 5 条内存占用稳定在 120MB无增长趋势SQLDatabaseChain生成错误 SQLLLM 对数据库 schema 理解偏差尤其字段别名和 JOIN 条件在prompt中强制插入 schema DDL 语句并添加约束“只生成 SELECT 语句禁止 INSERT/UPDATE/DELETE”SQL 错误率从 28% 降至 3.7%5.2 LlamaIndex 高频问题速查表问题现象根本原因解决方案实测效果增量索引后新文档查询不到VectorStoreIndex的insert_nodes()方法未刷新索引缓存调用insert_nodes()后必须手动执行index.storage_context.persist()并重启服务增量生效时间从“不定”缩短至 3 秒内query_engine.query()返回空结果但文档存在similarity_top_k设置过小或embedding_model与索引时使用的不一致检查index对象的embed_model属性确保与查询时完全相同将similarity_top_k临时设为 10 排查90% 的“空结果”问题由此解决中文文档检索召回率低常返回无关内容默认SentenceSplitter按英文标点切分中文标点识别失败自定义secondary_chunking_regex为[^。][。]?并启用paragraph_separator\n\n召回率从 58% 提升至 86%SummaryIndex查询速度慢P95 达 5sSummaryIndex需对整篇文档做摘要文档越大越慢仅对 5000 字的文档用SummaryIndex大文档强制切分后用VectorStoreIndex查询延迟从 5.2s 降至 0.4sCohereRerank重排序后结果更差top_n设置过大如 10引入过多噪声节点将top_n从 10 降至 3并在rerank后手动过滤score 0.3的节点重排序后准确率提升 12.4%而非下降5.3 通用避坑指南跨框架的 5 个致命误区误区一“用最新版就最稳”2024 年 LangChain v0.1.0 和 LlamaIndex v0.10.0 引入了重大 API 变更但生产环境必须用 LTS 版本。我们线上系统统一使用LangChain0.1.162023.12 LTS、LlamaIndex0.9.482024.03 LTS。新版本的LangGraph虽强大但文档缺失、社区支持弱上线前必须在预发环境压测 72 小时。误区二“向量模型越大越好”bge-large-zh比bge-small-zh在 MTEB 中文榜单高 8.2 分但实际项目中bge-small-zh的吞吐量是bge-large-zh的 3.7 倍。我们测算过在 32 核服务器上bge-small-zhQPS128bge-large-zhQPS34。选择依据不是榜单分数而是你的 SLA 要求——若 P95 延迟必须 1s则bge-small-zh是唯一选择。**误区三