混合检索实战：从零到精通，提升召回率17%，收藏必备！

本文详细介绍了混合检索系统在金融保险公司的应用通过BM25和向量检索的结合利用RRF算法实现结果融合有效提升了召回率17%。文章深入解析了BM25和向量检索的原理、参数设置以及RRF融合算法的实现细节和k值选择并提供了完整的代码实现。此外还分享了面试时如何回答混合检索相关问题的技巧以及实际部署中踩过的坑帮助读者更好地理解和应用混合检索技术。前段时间有个学员找我复盘他去面京东的AI算法岗项目经历里写了一个金融保险公司的RAG问答系统提到用混合检索把召回率提升了17%。面试官一上来就很感兴趣问他“你这个混合检索是怎么做的”他答“用了BM25加向量检索然后用RRF做结果融合。”面试官点点头追问“BM25和向量检索的权重比例你是怎么定的”他答“用了RRF不需要手动设置权重。”面试官继续追“RRF的k值你用的多少”他答“用的默认值60。”面试官追得更紧了“k60这个数字是怎么来的你为什么不用50不用100”他卡住了。面试官最后说了一句话“你能说出用了什么但说不出为什么这么用这在生产环境里是不够的。”这句话把问题说透了。混合检索不是把两种方法拼在一起那么简单每一个参数背后都有它的道理。今天我们就把这件事从头讲清楚。纯向量检索为什么不够用在讲混合检索之前得先搞清楚一个问题向量检索那么强为什么还需要BM25我们项目的背景是这样的金融保险公司文档库里有5000份保险合同和理赔文档用户通过对话系统查询保险条款、理赔规则、投保细节。这类场景有个非常典型的特点——用户的查询里经常包含大量专有名词和精确词。比如用户问“平安健康险2023版的等待期是多少天”这个查询里平安健康险2023版是一个精确的产品标识等待期是保险行业的专有术语。向量检索怎么处理这个查询它把整个问题编码成一个向量然后在文档库里找语义最相近的段落。问题来了向量模型学到的是语义相似性“等待期这个词在语义空间里和观察期”、“免责期”、生效时间都很接近。结果向量检索可能返回的是另一个产品比如中国人寿某款健康险的等待期条款因为语义上确实很像但产品名称对不上。这就是向量检索的核心弱点对精确关键词、产品编号、专有名词它的召回能力明显不足。BM25在这个场景下有天然优势。BM25是基于词频统计的检索算法平安健康险2023版这个字符串如果在某个文档里精确出现BM25就会给这个文档很高的分数。对于长尾稀疏查询——也就是那些包含特定词汇、在语料里出现频次不高的查询——BM25的表现往往好于向量检索。BM25 vs 向量检索 vs 混合检索 能力对比用一个具体数字说明在我们的测试集中对于包含产品名称或专有术语的查询纯向量检索的Recall5只有0.48而BM25单独使用能到0.71。但对于语义模糊、措辞多样的查询比如发生事故后要怎么报案用户可能说出险也可能说理赔申请BM25的召回率只有0.54向量检索能到0.79。两者各有擅长所以我们需要混合。要真正用好BM25光知道它擅长精确词匹配是不够的还得搞清楚它内部是怎么打分的参数背后是什么逻辑。BM25原理词频饱和与长度归一化BM25的全称是Best Match 25是Okapi BM25的简称Robertson等人在1990年代提出。它的核心公式是公式里有几个关键部分逐一拆开看。IDF逆文档频率一个词在越少文档里出现它的IDF越高说明这个词越有区分度。等待期在保险合同里不算高频词IDF相对较高保险这个词几乎每个文档都有IDF接近零对检索贡献很小。tf词频这个词在当前文档里出现了多少次。出现次数越多分数越高但BM25做了饱和处理。k1词频饱和参数默认1.5这是BM25最重要的参数之一。它控制词频对分数的边际贡献。如果k1很大词频越高分数越高线性增长如果k1很小词频超过一定次数后增益就趋于饱和。默认值1.5在大多数场景下表现稳定。在我们的保险文档场景里由于文档都是条款性文本词频分布比较均匀k1不需要调整。b长度归一化默认0.75控制文档长度对分数的影响程度。b1表示完全做长度归一化b0表示不做归一化。保险合同文档长短差异较大有的免责条款只有几百字有的理赔细则有几千字b0.75能有效避免长文档被过度惩罚。avgdl文档库中所有文档的平均长度|D|是当前文档长度。在Python里实现BM25我们用的是rank_bm25库代码如下from rank_bm25 import BM25Okapi import jieba classBM25Retriever: def__init__(self, documents, k11.5, b0.75): # 对文档做中文分词 tokenized_docs [list(jieba.cut(doc)) for doc in documents] self.bm25 BM25Okapi(tokenized_docs, k1k1, bb) self.documents documents defretrieve(self, query, top_k20): tokenized_query list(jieba.cut(query)) scores self.bm25.get_scores(tokenized_query) # 返回top_k个文档的索引和分数 top_indices scores.argsort()[-top_k:][::-1] return [(idx, scores[idx]) for idx in top_indices]如果线上系统已经有Elasticsearch也可以直接用ES自带的BM25实现。ES从5.0版本开始默认使用BM25替代TF-IDF配置如下{ settings: { similarity: { custom_bm25: { type: BM25, k1: 1.5, b: 0.75 } } }, mappings: { properties: { content: { type: text, similarity: custom_bm25 } } } }BM25这端搞清楚了另一端的向量检索同样有不少工程决策需要做尤其是中文场景下Embedding模型的选型选错了对效果影响很大。向量检索Embedding模型选择与索引结构向量检索这块中文场景下Embedding模型的选择直接影响召回质量。我们在项目里对比测试了几个方案text2vec-large-chinese中文优化在中文语义理解上表现不错但向量维度1024索引体积较大BGE-large-zhBAAI/bge-large-zh-v1.5当前中文开源Embedding效果最好的选项之一MTEB中文榜单长期排名靠前维度1024BGE-m3支持多语言在混合中英文的保险条款场景里有优势部分条款会引用英文缩写如IPO锁定期最终选了BGE-large-zh-v1.5在我们的业务测试集上比text2vec高出约4个百分点。Embedding生成代码from sentence_transformers import SentenceTransformer import numpy as np classVectorRetriever: def__init__(self, model_nameBAAI/bge-large-zh-v1.5): self.model SentenceTransformer(model_name) defencode(self, texts, batch_size32): # BGE模型推荐在查询前加前缀 if isinstance(texts, str): texts 为这个句子生成表示以用于检索相关文章 texts embeddings self.model.encode( texts, batch_sizebatch_size, normalize_embeddingsTrue# 归一化后可以用内积代替余弦距离 ) return embeddings defretrieve(self, query, index, top_k20): query_embedding self.encode(query) distances, indices index.search( np.array([query_embedding], dtypenp.float32), top_k ) return list(zip(indices[0], distances[0]))索引结构这里有一个常被忽视的选择问题Faiss提供多种索引类型常用的有两种IVFPQ倒排文件索引乘积量化离线批量构建和召回效率高内存占用小但需要训练阶段适合离线构建大规模索引。我们5000份文档经过分块后大约有8万个向量用IVF4096,PQ64配置内存占用约400MB批量召回QPS可以达到每秒数千次。HNSW层次可导航小世界图构建时间更长、内存占用更大但查询延迟极低P99在5ms以内适合线上实时检索。线上服务我们用HNSW离线评估和批量重建用IVFPQ。import faiss import numpy as np defbuild_hnsw_index(embeddings, dim1024, M32, ef_construction200): M: 每个节点的最大连接数越大精度越高但内存越大 ef_construction: 构建时的搜索范围越大精度越高但构建越慢 index faiss.IndexHNSWFlat(dim, M) index.hnsw.efConstruction ef_construction index.hnsw.efSearch 64 # 查询时的搜索范围 embeddings_array np.array(embeddings, dtypenp.float32) index.add(embeddings_array) return index两路检索各自准备好了下一个问题就是怎么把它们的结果合并在一起这正是面试官追问的核心——RRF。RRF融合算法k60从哪来的这是整篇文章最核心的部分也是面试官追问的关键。RRF的全称是Reciprocal Rank Fusion由Cormack、Clarke和Buettcher在2009年的SIGIR论文《Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods》中提出。算法本身非常简洁defrrf_fusion(bm25_results, vector_results, k60): bm25_results: BM25检索结果列表按分数降序排列元素为doc_id vector_results: 向量检索结果列表按相似度降序排列元素为doc_id k: RRF平滑参数默认60 返回: 按融合分数降序排列的(doc_id, score)列表 scores {} for rank, doc_id in enumerate(bm25_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(vector_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)混合检索 RRF 融合流程理解RRF的关键在于理解分数公式1/(krank1)的含义。rank从0开始排名第1的文档得分是1/(k1)排名第2是1/(k2)以此类推。如果一个文档在BM25结果和向量结果里都出现了它的最终分数就是两个1/(krank)的累加。k60是怎么来的Cormack等人在2009年的论文里做了大量实验测试了不同k值在多个IR基准数据集上的表现。实验结论是k60在大多数场景下能取得最佳的融合效果而且对k值的选取不是特别敏感——k在40到80之间性能差异通常在1%以内。从数学直觉上理解k的作用是控制排名靠前的文档相对于后面文档的权重差距。k很小比如k1排名第1的文档分数1/20.5排名第2是1/3≈0.33差距巨大算法对最高排名文档极度敏感k很大比如k1000排名第1是1/1001≈0.001排名第20是1/1020≈0.00098差距极小几乎把所有文档都拉平了k60排名第1是1/61≈0.0164排名第20是1/800.0125保持了合理的排名差距同时对噪声不过度敏感用Python验证一下不同k值的分数分布defcompare_k_values(top_n10): k_values [1, 10, 60, 100, 1000] print(f{rank:6}, end) for k in k_values: print(f{kstr(k):12}, end) print() for rank in range(top_n): print(f{rank1:6}, end) for k in k_values: score 1 / (k rank 1) print(f{score:12.5f}, end) print() compare_k_values() # 输出示例 # rank k1 k10 k60 k100 k1000 # 1 0.50000 0.09091 0.01639 0.00990 0.00100 # 2 0.33333 0.08333 0.01613 0.00980 0.00100 # 10 0.09091 0.04762 0.01429 0.00909 0.00099为什么用RRF而不是加权求和这是另一个面试高频追问。加权求和的方式是final_score α * bm25_normalized_score (1-α) * vector_normalized_score这个方式有一个致命问题BM25的分数和向量相似度分数的量纲完全不同。BM25分数受文档库大小、词频分布影响可能是0.1到50的任意范围向量相似度经过归一化后在0到1之间。直接加权求和前必须对两路分数做归一化而归一化方式的选择又会引入新的超参数且在不同批次的检索结果里分数范围可能变化。RRF完全绕开了这个问题——它只用排名不用分数。无论BM25返回的分数是0.3还是30排名第1就是排名第1得分1/(k1)。这使得RRF在跨批次、跨模型更新时表现非常稳定不需要重新校准归一化参数。标准RRF默认把两路结果等权融合但实际业务中有时候需要让某一路的贡献更大一些。这就引出了下一个问题如果非要手动调整权重该怎么做权重调优如果非要加权怎么做RRF默认的行为是两路等权融合但有时候业务上确实需要调整两路的权重。比如我们发现在理赔查询类问题中BM25更可靠而在产品咨询类问题中向量检索更稳定。加权RRF的公式是score α * 1/(k rank_bm25 1) (1-α) * 1/(k rank_vector 1)实现代码defweighted_rrf_fusion(bm25_results, vector_results,k60,alpha0.5): alpha: BM25的权重1-alpha是向量检索的权重alpha0.5等价于标准RRF alpha0.5更偏重BM25适合精确词查询多的场景 alpha0.5更偏重向量检索适合语义查询多的场景 scores{}forrank, doc_idinenumerate(bm25_results): scores[doc_id]scores.get(doc_id,0) alpha *(1/(k rank 1))forrank, doc_idinenumerate(vector_results): scores[doc_id]scores.get(doc_id,0)(1- alpha)*(1/(k rank 1))returnsorted(scores.items(),keylambda x: x[1],reverseTrue)alpha值通过在验证集上做网格搜索确定。我们的做法是准备了一个500条人工标注的查询集覆盖精确词查询、语义查询、混合查询三类然后import numpy as np from tqdm import tqdm def evaluate_recall_at_k(fusion_results, ground_truth, k5): 计算Recallk hits 0 for query_id, relevant_docs in ground_truth.items(): top_k_docs [doc_id for doc_id, _ in fusion_results[query_id][:k]] if any(doc in top_k_docs for doc in relevant_docs): hits 1 return hits / len(ground_truth) # 网格搜索最优alpha best_alpha 0.5 best_recall 0.0 alpha_range np.arange(0.1, 1.0, 0.1) for alpha in tqdm(alpha_range): fusion_results {} for query_id, query in validation_queries.items(): bm25_res bm25_retriever.retrieve(query, top_k20) vector_res vector_retriever.retrieve(query, faiss_index, top_k20) bm25_doc_ids [idx for idx, _ in bm25_res] vector_doc_ids [idx for idx, _ in vector_res] fusion_results[query_id] weighted_rrf_fusion( bm25_doc_ids, vector_doc_ids, k60, alphaalpha ) recall evaluate_recall_at_k(fusion_results, ground_truth, k5) if recall best_recall: best_recall recall best_alpha alpha print(f最优alpha: {best_alpha:.1f}, 对应Recall5: {best_recall:.4f}) # 我们项目的结果: 最优alpha: 0.4, 对应Recall5: 0.8921 # alpha0.4意味着向量检索权重略高符合我们文档以语义查询为主的特点对于k值本身如果业务场景特殊比如文档库非常小只有几百个文档也可以做类似的网格搜索验证k60是否仍然最优。我们在5000份文档上验证过k60确实是局部最优k40和k80的Recall5差距在0.3%以内。参数调好了最终到底能带来多大提升下面用实际数据说话。实战效果混合检索带来了什么混合检索 vs 纯向量检索 效果对比上线混合检索之前我们在测试集上做了完整的A/B对比整体Recall5从0.72提升到0.89绝对提升17个百分点。拆分来看语义查询类如发生意外如何申请理赔从0.79提升到0.85提升约6个百分点。这类查询向量检索本来就做得不错BM25的补充效果有限但RRF融合后依然有小幅提升因为BM25能额外召回一些包含关键动词的相关文档。精确词查询类如重疾险豁免条款第三条从0.51提升到0.78提升约27个百分点。BM25在这类查询上贡献最大豁免条款第三条这样的精确词组BM25几乎能100%命中而向量检索则可能把豁免条款第二条也排进来。专有名词查询类如平安健康险2023版等待期从0.48提升到0.73提升约25个百分点。这是提升最显著的一类BM25对产品型号、年份、专业术语的精确匹配能力是关键。值得一提的是混合检索对检索延迟的影响较小。BM25的检索速度极快毫秒级向量检索HNSW索引P99延迟约5msRRF融合本身是纯Python列表操作不到1ms。整体端到端检索延迟从约7ms增加到约9ms对用户感知无影响。上面分开介绍了各个模块实际项目里当然是把它们组合成一个完整的类来用下面直接给出可以拿来参考的实现。完整的混合检索实现把上面所有部分组合成一个完整的检索类供参考class HybridRetriever: def __init__( self, documents, embedding_modelBAAI/bge-large-zh-v1.5, bm25_k11.5, bm25_b0.75, rrf_k60, alpha0.5 ): self.documents documents self.rrf_k rrf_k self.alpha alpha # 初始化BM25 self.bm25_retriever BM25Retriever( documents, k1bm25_k1, bbm25_b ) # 初始化向量检索 self.vector_retriever VectorRetriever(embedding_model) # 构建Faiss HNSW索引 print(正在构建向量索引...) embeddings self.vector_retriever.encode(documents) self.faiss_index build_hnsw_index( embeddings, dimembeddings.shape[1] ) print(f索引构建完成共{len(documents)}个文档) def retrieve(self, query, top_k5, bm25_candidate20, vector_candidate20): # BM25检索 bm25_results self.bm25_retriever.retrieve(query, top_kbm25_candidate) bm25_doc_ids [idx for idx, _ in bm25_results] # 向量检索 vector_results self.vector_retriever.retrieve( query, self.faiss_index, top_kvector_candidate ) vector_doc_ids [idx for idx, _ in vector_results] # RRF融合 fused weighted_rrf_fusion( bm25_doc_ids, vector_doc_ids, kself.rrf_k, alphaself.alpha ) # 返回top_k结果 top_results fused[:top_k] return [ { doc_id: doc_id, content: self.documents[doc_id], rrf_score: score } for doc_id, score in top_results ]代码层面的东西梳理清楚了最后来说一个更实际的问题面试的时候遇到这类追问该怎么组织语言回答才最有效面试怎么答混合检索这是面试中最容易被追问到底的技术点回答要有层次大约30-40秒说清楚。分4步走第一步说背景和问题5秒先交代为什么要用混合检索。“我们的RAG系统在处理包含产品编号、专业术语的精确词查询时纯向量检索的召回率只有0.48存在明显的召回短板。”第二步说方案选择10秒说清楚为什么选BM25向量RRF这个组合而不是其他方案。“BM25对精确词匹配有天然优势向量检索擅长语义匹配两者互补。RRF做融合是因为它不需要对两路分数做归一化鲁棒性好这是Cormack 2009年论文的结论k60是论文实验中在多个数据集上表现最稳定的值。”第三步说实现细节10秒说出你真正做了什么。“每路各取Top20候选RRF融合后返回Top5。如果需要调整两路权重用加权RRFalpha通过在500条标注验证集上网格搜索确定我们的最优值是0.4略微偏向向量检索。”第四步说效果和数据10秒用数字收尾显示你有量化评估意识。“上线后整体Recall5从0.72提升到0.89含专有名词的查询提升约25个百分点检索延迟仅增加约2ms整体在可接受范围内。”这4步说完面试官大概率不会再追问因为你已经把背景、原理、实现、效果都覆盖了而且每个点都有具体数字支撑不是泛泛而谈。光有理论框架还不够真实部署中踩过的坑往往比原理更能打动面试官也更能说明你真正上过生产。一些踩坑经验最后补充几个在实际部署中遇到的问题这类细节在面试里往往能让你加分。中文分词的质量直接影响BM25效果。Jieba默认词典不包含保险行业专有词汇“免赔额可能被切成免/赔额”“等待期可能被切成等待/期”。我们的解决方案是给Jieba添加自定义词典把5000份文档里出现的保险专业术语全部收录进来这一步让BM25的精确词召回率额外提升了约8个百分点。import jieba # 加载自定义词典保险行业专有词汇 jieba.load_userdict(/path/to/insurance_terms.txt) # insurance_terms.txt格式每行一个词可附词频和词性 # 等待期 100 n # 免赔额 100 n # 豁免条款 100 n # 重疾险 100 n候选集大小的选择有讲究。我们每路取Top20这个数字不是随意选的。Top5太少两路的交集可能非常少RRF融合的价值没有充分体现Top100太多会引入大量噪声。我们实验的结论是对于5000份文档、每份平均切分成16个块的情况每路Top20是效果与效率的最佳平衡点。BGE模型的查询前缀不能忘。BGE系列模型在训练时对查询和文档使用了不同的前缀格式查询需要加为这个句子生成表示以用于检索相关文章的前缀文档编码不需要加。如果忘了加前缀召回率会下降约3-5个百分点。这些细节都是在生产环境里真实踩过的坑面试时提到一两个会让面试官感受到你有实战经验不只是在背理论。把上面所有内容串起来做个收尾。总结混合检索解决的核心问题是向量检索的语义理解能力和BM25的精确词匹配能力各有短板单独使用都无法覆盖所有查询类型。RRF融合算法用一个极简的公式1/(krank)把两路结果整合起来k60来自2009年论文的实验验证代表的是在分数敏感度和排名稳定性之间的最优平衡。在实际部署中分词质量、候选集大小、模型前缀这些工程细节和算法本身同样重要。最后对于正在迷茫择业、想转行提升或是刚入门的程序员、编程小白来说有一个问题几乎人人都在问未来10年什么领域的职业发展潜力最大答案只有一个人工智能尤其是大模型方向当下人工智能行业正处于爆发式增长期其中大模型相关岗位更是供不应求薪资待遇直接拉满——字节跳动作为AI领域的头部玩家给硕士毕业的优质AI人才含大模型相关方向开出的月基础工资高达5万—6万元即便是非“人才计划”的普通应聘者月基础工资也能稳定在4万元左右。再看阿里、腾讯两大互联网大厂非“人才计划”的AI相关岗位应聘者月基础工资也约有3万元远超其他行业同资历岗位的薪资水平对于程序员、小白来说无疑是绝佳的转型和提升赛道。对于想入局大模型、抢占未来10年行业红利的程序员和小白来说现在正是最好的学习时机行业缺口大、大厂需求旺、薪资天花板高只要找准学习方向稳步提升技能就能轻松摆脱“低薪困境”抓住AI时代的职业机遇。如果你还不知道从何开始我自己整理一套全网最全最细的大模型零基础教程我也是一路自学走过来的很清楚小白前期学习的痛楚你要是没有方向还没有好的资源根本学不到东西下面是我整理的大模型学习资源希望能帮到你。扫码免费领取全部内容1、大模型学习路线2、从0到进阶大模型学习视频教程从入门到进阶这里都有跟着老师学习事半功倍。3、 入门必看大模型学习书籍文档.pdf书面上的技术书籍确实太多了这些是我精选出来的还有很多不在图里4、AI大模型最新行业报告2026最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共90天可落地执行第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】