别再只玩向量相似度了！BM25和SPLADE才是RAG检索的隐藏大招，一文打通稀疏嵌入的任督二脉！全文围绕《大模型RAG生成式AI开发实战》第14章核心内容，从稠密嵌入的盲区切入，手把手拆解BM25的概率检索本质与调参玄学，再揭开SPLADE利用BERT做词汇扩展的神秘面纱。最后给你一套能直接落地的混合检索工程方案与评估方法论。读完这篇，你不仅能分清楚什么时候该用老江湖BM25，什么时候该上新锐SPLADE，更能把两路召回打出漂亮的组合拳，让你的RAG系统告别“语义近似但精准稀碎”的翻车现场。

文字目录：

• 要点1：从稠密到稀疏——为什么RAG需要BM25这根“老骨头”
• 要点2：BM25不是黑盒——k1和b参数到底怎么调
• 要点3：SPLADE登场——让BERT学会“造词”的稀疏嵌入新贵
• 要点4：BM25 vs SPLADE——不是谁替代谁，而是“组合拳”
• 要点5：RAG系统中的工程落地——从理论到代码的思维跃迁
• 要点6：评估与优化——你的稀疏检索真的work了吗？
• 写在最后

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》138.[第14章 嵌入模型深度解析] 稀疏嵌入：BM25和SPLADE方法

老话说得好，“手里拿着锤子，看什么都像钉子”。现在很多兄弟做RAG，手里就攥着一个稠密向量检索工具，不管啥场景都硬往里套。用户搜个专业术语，召回的却是八竿子打不着的“语义相近”文档；搜个生僻词，直接查无此条。结果呢？大模型拿着这些不靠谱的上下文开始一本正经地胡说八道，幻觉没减少，老板的脸却越来越黑。

你是不是也这样？总觉得向量数据库装上、Embedding模型一跑，检索就稳了？醒醒吧，那是你没遇到真正的“术语Boss”和“冷僻词精英”。今天咱就把这根“钉子思维”拔出来，好好聊聊稀疏嵌入里的两员大将：BM25这位身经百战的老江湖，以及SPLADE这位会玩词汇扩展的新锐。坐稳了，这趟车专治各种检索不服。

要点1：从稠密到稀疏——为什么RAG需要BM25这根“老骨头”

点题

咱们先掰扯清楚，啥是稠密嵌入，啥又是稀疏嵌入。

稠密嵌入，就是你把一句话扔进BERT或者Sentence-Transformer，吐出来一个固定长度的浮点数向量，比如768维。然后靠余弦相似度或者点积，在向量空间里找邻居。这套玩法语义泛化能力强，两个词就算长得不一样，只要在语义空间里离得近，就能被捞回来。

但问题也出在这儿。向量空间是个“圆滑”的地方，它擅长捕捉“大概意思”，却常常搞不定“精确命中”。

稀疏嵌入则完全另一套逻辑。它的向量维度超高，通常是几万维，对应整个词表，但绝大多数位置是0，只有出现过的词才有权重。BM25就是这类稀疏检索的代表，它本质上是一套基于概率检索框架的排序函数，可以看作TF-IDF的究极进化版。

在RAG里，BM25负责的是“你说了这个词，我就必须把包含这个词的文档给你找出来”的硬逻辑。

痛点分析

新手做RAG，最容易踩的坑就是“All-in向量检索”。

觉得关键词匹配是上一代技术，过时了，土了。上来就Milvus、Faiss、Pinecone一套组合拳，文本往里头一塞，Query往里一丢， cosine similarity 跑分，取Top5，完事儿。刚开始测试“如何学习Python”这种泛泛而谈的问题，效果还真不错，心里美滋滋，觉得稳了。

但一旦上线真实业务，翻车翻得你怀疑人生。

举个具体例子。你做了一个电商客服RAG，用户问：“iPhone 15 Pro Max 1TB 蓝色钛金属现在多少钱？” 稠密向量检索召回的是“iPhone 15 Pro Max 256GB 黑色”和“iPhone 14 Pro Max 选购指南”。为啥？因为在语义空间里，它们都是苹果手机，都是Pro Max，距离近得跟亲兄弟似的。但用户明明明确指定了“1TB”和“蓝色”，稠密向量把这两个关键信息给“平滑”掉了。

更离谱的是医疗、法律场景。用户搜“阿奇霉素儿童用量”，召回个“阿莫西林成人用量”，语义近吗？近，都是抗生素。但敢拿来生成回答吗？那是要出大事的。

这时候你就焦虑了。明明用了最前沿的RAG架构，为什么连最基本的关键词匹配都做不好？大模型开始 hallucinate，你开始疯狂改Prompt，企图让LLM自己纠偏。但这属于头痛医脚，根子出在检索上。

解决方案

正确认知应该是：稠密向量负责“语义相关”，稀疏嵌入负责“精确命中”。一个管广度，一个管精度，RAG检索绝对不能只靠一只脚走路。

BM25怎么做？它看三个核心东西：

第一，词频（TF）。一个词在文档里出现越多，相关性越高，但BM25有个“饱和”机制，不会 let 高频词无限刷分。

第二，逆文档频率（IDF）。一个词在整个库中越稀有，区分度越高，权重越大。像“的”、“了”这种到处都有的词，IDF直接给打下去。

第三，文档长度归一化。长文档天然词多，不能让它占便宜，BM25会按平均长度做惩罚。

在工程上，落地BM25几乎零成本。Elasticsearch、OpenSearch原生就是干这个的。如果你的RAG之前只有向量库，现在赶紧加一路ES做BM25召回，做个Hybrid Search，成本极低，还不需要GPU。

就拿前面那个iPhone案例来说。加入BM25通道后，“1TB”和“蓝色钛金属”作为高区分度词汇，IDF权重直接起飞，包含精确匹配的文档能被顶到第一位。大模型拿到了准确的上下文，回答自然靠谱。

小结

稠密向量是广度，稀疏嵌入是精度。做RAG如果只玩向量相似度，遇到专有名词和精确属性查询，大概率要翻车。

要点2：BM25不是黑盒——k1和b参数到底怎么调

点题

很多新手把BM25当黑盒用，Elasticsearch默认参数一跑到底，就觉得这事儿跟自己没关系了。但其实BM25里面就两个核心参数：k1和b。理解这俩兄弟，你的检索质量能往上蹿一截。

先通俗解释一下BM25的评分逻辑。它本质上是在算：

Score = IDF × （词频 × (k1 + 1)） / （词频 + k1 × (1 - b + b × 文档长度/平均长度)）

k1控制的是“词频饱和度”。k1越大，词频对最终得分的影响越接近线性，越容易饱和。默认一般在1.2到1.5之间。

b控制的是“文档长度惩罚力度”。b在0到1之间，b=0意味着完全不惩罚长度；b=1意味着长文档会被严厉惩罚。默认一般是0.75。

痛点分析

用默认参数跑所有场景，是新手最常见的错误做法。

你想想，ES默认k1=1.2，b=0.75。这套参数是针对通用英文文档集（比如TREC这种新闻语料）调出来的。你的场景可能是法律法条，也可能是微博短评，也可能是电商标题，直接套默认值，不翻车才怪。

说个真实感极强的案例。你做法务助手RAG，文档都是《民法典》条文、司法解释，动辄上千字。这时候b=0.75会疯狂惩罚长文档。明明某条司法解释完美匹配用户问题，就因为它是长文本，得分被砍了一半，排到了第三页。用户根本看不到。

反过来，如果你做的是一个短文本问答系统，比如知乎风格的“如何评价某电影”，文档都很短。这时候b=0.75反而让短文档占了过多便宜，稍微沾点边的短回答把长篇深度分析都给压下去了。

还有k1。如果你的场景是标题检索，或者用户Query很短，比如就两三个词，k1=1.2可能太大了。某个词在标题里出现两次，得分就被拉得过高，结果排序被高频但不精准的结果霸榜。

这时候你头皮发麻，看着检索结果“感觉不对”，但不知道咋整。去搜博客，一堆复制粘贴的BM25公式讲解，看完还是不会调。最后只能疯狂加过滤条件，或者干脆在业务层写死规则，系统越来越臃肿。

解决方案

调参不是玄学，是有套路的。

k1怎么调？

如果你的文本是长文，且词频分布比较均匀，k1可以保持在1.2到2.0之间。如果是短查询、标题匹配，建议把k1降到0.5到1.0。目的是避免单个高频词把分数刷爆。

b怎么调？

这是最容易出效果的。如果你领域里的文档长度差异极大——比如同时有短篇博客和长篇论文——b就需要重点打磨。

• 长文本领域（法律、论文、书籍）：建议b降到0.3到0.5。不要让长文档被过度惩罚，毕竟长文信息量大，理应获得公平机会。
• 短文本领域（微博、评论、商品标题）：b可以保持0.75，甚至提到0.9，让短文本的优势更明显。
• 文档长度比较均匀的：b=0.75就挺好，不用折腾。

在Elasticsearch里，你可以在mapping里自定义similarity：

PUT /my_index
{
  "settings": {
    "similarity": {
      "my_bm25": {
        "type": "BM25",
        "k1": 0.9,
        "b": 0.4
      }
    }
  }
}

调完参数，一定要用离线数据集测NDCG或者MRR的变化。别凭感觉。法律文档那个案例，把b从0.75调到0.3之后，长尾法条的召回率直接涨了20%以上，效果立竿见影。

小结

BM25的k1和b不是摆设，它们分别回答了两个问题：词频到底该多重要？长文档该不该吃亏？理解了这个，你才算真正驾驭了BM25。

要点3：SPLADE登场——让BERT学会“造词”的稀疏嵌入新贵

点题

BM25很强，但它有个天生的短板：硬匹配。文档里没出现这个词，BM25就给零分，毫无商量余地。

可现实世界很残酷。用户搜“水果公司的手机”，文档里写的是“Apple iPhone”。用户问“COVID-19后遗症”，文档里出现的是“新型冠状病毒感染长期症状”。这种字面不匹配但语义高度相关的情况，BM25只能干瞪眼。

这时候，SPLADE来了。

SPLADE全称 Sparse Lexical and Expansion Model，是近几年神经稀疏检索的扛把子。它的核心思想特别巧妙：利用BERT的MLM（Masked Language Model）头，对输入文本的每个token，输出整个词表上每个词的概率分布。

也就是说，你喂给SPLADE一句话，它不仅记录原句里的词，还会给相关但没来过的词也打上权重。相当于让BERT做了一次“词汇联想”和“查询扩展”。

最后把整句话在所有token上扩展出来的词表分布聚合起来（通常是Max Pooling加对数饱和），就得到了一个维度等于词表大小、但极度稀疏的向量。

查询端和文档端都这么操作，然后做点积，相关性分数就出来了。

痛点分析

很多新手对稀疏嵌入的认知还停留在TF-IDF和BM25这个阶段，完全不知道还有SPLADE这种“学习型稀疏向量”。一看到论文里写“Sparse”，就以为是传统倒排索引那套老东西，直接跳过。

还有一种更惨的：知道SPLADE很牛，但不知道怎么落地。一看输出是“维度30000+的稀疏向量”，整个人都懵了。这玩意儿怎么存？Faiss支持吗？和BM25的倒排索引是一回事吗？

我见过一个典型的翻车案例。某团队看了SPLADE论文，觉得这就是未来，连夜把生产环境的ES全换成自研的SPLADE服务。结果代码里的类名、API名（比如AbstractApplicationContext）检索准确率暴跌。为啥？因为SPLADE的MLM对训练语料里少见的复合技术词汇扩展能力不稳定，它可能把Context扩展出一堆无关的上下文含义，反而把精确匹配给搅浑了。

另一个常见误区是：以为SPLADE向量可以直接塞进BM25的倒排索引里。这完全是两码事。BM25的索引是词项到文档的倒排表，SPLADE的向量虽然也是稀疏的，但它的权重是神经网络算出来的连续浮点数，存储和检索都需要专门的稀疏向量支持。

这时候你心里就开始打鼓了。追新怕翻车，守旧怕落后，SPLADE到底靠不靠谱？

解决方案

首先，建立正确认知。SPLADE不是BM25的替代品，而是填补了“语义扩展”这块拼图。

它的最佳战场是：查询短、需要语义联想、且字面匹配容易失败的场景。比如开放式问答、闲聊式检索、同义词极多的领域（医疗、法律口语化表达）。

工程落地上，别再自己造轮子了。Milvus 2.4+已经原生支持稀疏向量，Qdrant也支持，直接用它们的稀疏向量索引就行。向量维度虽高，但因为是稀疏的，实际存储和计算成本比稠密向量低得多。

如果你担心SPLADE在技术术语上扩展不稳定，可以采用“双塔”策略：BM25保精确，SPLADE保扩展，两路召回互相兜底。这个咱们在下一个要点细说。

还是前面那个“水果公司的手机”的例子。BM25搜“水果”只能找到真的在讲苹果、香蕉的文档。但SPLADE通过BERT的语义理解，能把“水果公司”和“Apple”在向量空间关联上，从而召回苹果的官方介绍。这就是它的魔力所在。

小结

SPLADE不是魔法，而是让稀疏检索长出了“语义联想”的翅膀，专治字面不匹配但语义相关的检索顽疾。

要点4：BM25 vs SPLADE——不是谁替代谁，而是“组合拳”

点题

聊到这儿，你可能要问了：大仙，那我到底选BM25还是SPLADE？

如果你脑子里是非此即彼的二选一，那这题就答错了。在真实的RAG系统里，这两位不是对手，而是队友。

咱们列个对比，看得更清楚：

BM25的优势在于零样本能力极强，开箱即用，不需要训练数据；它是白盒，可解释，你知道为什么某个文档排前面；性能炸裂，CPU上毫秒级响应。

SPLADE的优势在于语义扩展能力强，能跨词汇做关联；对短查询特别友好；能捕捉到BM25死活抓不到的同义表达。

但SPLADE也有软肋：它需要模型推理，延迟比BM25高；对罕见词、专业复合词的扩展不一定稳定；是个黑盒，出错了不好debug。

痛点分析

二极管思维是技术选型里最要命的。

要么团队A，保守派，认定“神经网络都是花架子”，守着BM25五年不动摇，结果用户在自然语言问答里搜口语化表达，体验被隔壁竞品吊打。

要么团队B，激进派，看了几篇论文吹SPLADE，就把生产环境全换了，结果QPS扛不住，术语检索还退步，半夜被运维打电话叫醒。

还有一种隐藏的坑：强行把两路召回的分数直接加权融合。BM25的分数可能是0到100，SPLADE做点积可能是0到20，余弦相似度可能是0到1。你直接0.7×A + 0.3×B，由于量纲不同，基本上就是某一路在主导，另一路陪跑。融合了个寂寞。

解决方案

成年人不做选择，成年人要学会打组合拳。业内最稳妥的方案是RRF，Reciprocal Rank Fusion，倒数排序融合。

公式极其优雅：

Score = Σ 1 / (k + rank_i)

k通常取60，是个经验值。它只看每路召回里的排序位次，不看原始分数。这就完美避开了“BM25分高还是SPLADE分高”的量纲灾难。

具体做法：

第一步，用户Query同时发给BM25索引和SPLADE编码服务。

第二步，BM25召回Top 100，SPLADE也召回Top 100。

第三步，对两路结果的排序位次算RRF分数。比如某个文档在BM25排第2，在SPLADE排第8，它的RRF分就是 1/(60+2) + 1/(60+8)。

第四步，按RRF总分重排，取Top K送给大模型。

技术文档场景下，BM25保证类名、API名、错误码的精准命中；SPLADE保证功能描述、概念解释的相关性。融合后，MRR@10经常比单路提升25%到35%。

如果你有资源，甚至可以玩三路：Dense（语义）+ BM25（精确）+ SPLADE（扩展），先用RRF融合，再送给LLM。但新手先把两路玩明白，别贪多。

小结

检索系统的天花板，从来不取决于你用了多新的模型，而取决于你能不能把手里的牌打出组合技。

要点5：RAG系统中的工程落地——从理论到代码的思维跃迁

点题

理论再花哨，落不了地就是纸上谈兵。这一节咱们聊点硬的：稀疏嵌入在RAG Pipeline里到底怎么接？

整个数据流大概是：用户Query进来，分成两路（或多路），分别做稠密编码和稀疏编码，然后扔进各自的数据库做召回，Gateway层做融合，最后把文档塞给LLM。

痛点分析

新手在这一步最容易踩三个大坑。

第一，串行执行坑。

代码里先调向量库，等100ms返回了，再去调ES做BM25，再等50ms，最后融合。RT直接累加到150ms以上。用户点一下搜索，眼睛盯着转圈圈，体验稀碎。

第二，分数乱炖坑。

前面提过，ES的_score、向量余弦相似度、SPLADE点积，三者的数值范围和业务含义完全不同。有人直接做个加权平均，结果某一路分数量级太大，另一路直接被淹没了，所谓的融合只是自欺欺人。

第三，存储选型坑。

老项目可能已经有ES了，做BM25没问题，但想把SPLADE向量也塞进ES？可以，但ES的稀疏向量支持跟专门的向量库比起来，查询语法和性能曲线都不一样。新项目如果选型失误，后面迁移成本极高。

还有一个隐形痛点：文档ID不统一。稠密向量库返回doc_id=42，ES返回_id="abc123"，融合的时候对不上号，去重逻辑写得稀烂，最后给LLM送了重复文档，浪费token。

解决方案

咱们逐个击破。

并行召回是底线。

两路检索必须并发发起。在Python里可以用asyncio.gather，在Java里用CompletableFuture.allOf。RT由最慢的那一路决定，而不是累加。比如稠密检索100ms，BM25 20ms，并行后总RT约100ms，而不是120ms。

分数无关化。

忘掉原始分数，用RRF。如果一定要加权，也请先做归一化（比如Min-Max把各路分数压到0-1），但RRF通常更稳。不要在某一路分数不稳定的时候，搞什么动态权重，那会让你的系统变成玄学。

统一ID空间。

入库的时候，不管是进ES还是进Milvus，文档都必须带同一个doc_id。融合层只认这一个ID，按ID去重，按RRF重排。

数据库选型建议：

• 如果团队已经有ES，且主要用BM25：保留ES做稀疏检索。SPLADE可以走单独的服务，存到支持稀疏向量的Milvus或Qdrant里，Gateway层做RRF融合。
• 如果是新项目：直接上Milvus 2.4+，它同时支持稠密向量、稀疏向量和Hybrid Search，一套API，一套运维，省事儿。
• 别试图用传统Faiss存SPLADE的稀疏向量，那属于给自己找不痛快。

案例： 某团队把串行改并行，RT从800ms降到280ms；引入RRF后，头部结果的相关性满意度从62%提到89%。

小结

工程落地的精髓不是用最酷的技术，而是让不同的检索通道在同一个Pipeline里和谐共处，低延迟、高稳定地跑出结果。

要点6：评估与优化——你的稀疏检索真的work了吗？

点题

很多团队做RAG，检索环节是没有评估的。上线靠“感觉”，优化靠“拍脑袋”。sparse embedding有没有效，全凭大模型最终回答好不好来判断。这种思路极其危险，因为大模型是最后一环，前面的检索烂，它可能只是靠嘴硬给圆回来了，你根本发现不了。

正确的姿势是：给检索单独建评估体系。

核心指标就那么几个：

• Recall@K：前K个结果里，有没有包含正确答案。
• MRR（Mean Reciprocal Rank）：正确答案的平均倒数排名，看排序质量。
• NDCG：考虑相关性分级后的排序增益，比MRR更细腻。

痛点分析

最常见的情况是：没有离线测试集。

每次觉得检索效果不好，就直接改线上参数，或者升级LLM模型。这是一种极其昂贵的试错。更隐蔽的错误是：把HitRate当唯一指标。只要正确答案出现在Top50里，就算命中。但RAG通常只取Top5给LLM，排第49跟没排进来区别不大。

还有一个思维误区，我称之为“大模型背锅症”。

生成的回答错了，第一反应是“GPT-4还不够强，换Claude 3.5试试”。结果花大钱换了更强的模型，问题依旧。最后一查日志，发现正确答案在BM25里排第8位，在SPLADE里排第12位，LLM根本看不到。你升级模型有什么用？它又不是透视眼。

案例：某医疗问答系统，团队疯狂优化Prompt，要求模型“不要胡说”。但用户问“二甲双胍的禁忌症”，BM25把相关说明书排到了第6位，LLM拿到前5个都是无关文档，只能开始编。团队折腾两周Prompt，不如把BM25的b参数调一下，让长文档少受点惩罚，或者加一路SPLADE把“禁忌症”和“不良反应”关联起来。

解决方案

建立轻量级、可持续的评估流水线。

第一步，构建黄金评估集。

从线上日志里抽样100到500条真实Query，人工标注对应的黄金文档（最相关的1到3篇）。不需要多，但要有代表性。每周跑一次自动化评测。

第二步，拆解指标，精准打击。

• 如果BM25的Recall@5低：检查中文分词器。中文千万别用默认的空格分词，必须上IK Analyzer、jieba或者HanLP。检查同义词词典，比如“电脑”和“计算机”有没有做等价。
• 如果SPLADE的NDCG低：大概率是模型没在你领域微调过。通用SPLADE在电商上表现不错，但在医疗、法律、工业制造领域可能水土不服。收集领域语料做继续预训练或对比学习微调。
• 如果融合后的MRR低：检查两路结果的重叠度。如果BM25和SPLADE召回的Top10几乎完全不重叠，说明有一路可能已经跑偏了，需要分别debug。

第三步，线上可观测。

记录每次Query的两路召回doc_id列表。用户投诉的时候，你可以精准回溯：“这次BM25召回了ABC，SPLADE召回了DEF，融合后G排第一，但正确答案H其实在BM25的第9位。” 有数据，优化才有方向。

案例： 通过离线集发现SPLADE把“Java”错误扩展成了“JavaScript”，导致召回了一堆前端文档。团队在训练数据里加了负样本对（“Java” vs “JavaScript”文档做对比学习），微调后该问题消失，NDCG@10提升15%。

小结

评估是检索系统的罗盘，没有它，你在BM25和SPLADE的参数海洋里就是一艘没有方向的船。

写在最后

看到这里，相信你对BM25和SPLADE已经不再陌生了。一个是身经百战、零样本即可出战的老将，一个是懂得语义扩展、能联想会造词的新锐。在RAG这条路上，它们不是非此即彼的敌人，而是能打出漂亮配合的战友。

做技术最忌讳的就是盲目追新，也最忌讳固步自封。稠密向量、BM25、SPLADE，甚至未来的其他稀疏模型，本质上都是工具。真正值钱的是你对业务场景的理解，是你知道什么时候该让BM25去守精确匹配的底线，什么时候该让SPLADE去突破字面表达的边界。

编程之路不易，检索系统的调优更是一场漫长的修行。但每一步扎实的评估、每一次参数的微调、每一路召回通道的精心搭建，都算数。保持好奇，持续动手，别怕在Bad Case里迷路，因为那都是你变强的路标。

你的RAG系统，值得拥有一套既能精准命中、又能语义联想的稀疏检索组合拳。去试试吧，我相信你能搞定。

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》