今天学点啥？每天10分钟，拆解一个真实岗位JD，搞懂一个大模型技术点。

今天拆解的是阿里巴巴智能信息事业部的LLM算法岗，薪资给到了40-70K·16薪（年薪最高112万），JD中的技术要求如下：

• ✅ 前沿探索：跟踪、研究大语言模型相关领域，包括但不限于模型预训练、指令微调、强化学习、检索增强生成(RAG)、AI Agent等

• ✅ 业务赋能：基于大规模用户行为数据和高质量标注数据，设计并构建LLM解决方案，以支持搜索广告和信息流广告相关业务

• ✅ 专业技能：熟悉prompt工程及常用的SFT数据构建方式，了解RAG、AI Agent框架

在阿里这个70K的算法岗中，RAG被多次明确提及，足见其重要性。

一、RAG是什么？

想深入了解RAG是什么？我们先看一个真实场景：

你在淘宝问客服："我上个月买的羽绒服，尺码偏大想换小一号，怎么办？"

• 传统LLM： "您好，关于商品换货，一般需要在收货后7天内申请..."（标准话术，没解决问题）

• 用了RAG的智能客服： "您好，查询到您10月5日购买的XX品牌羽绒服（订单号123456），该商品支持7天无理由退换。由于您购买的黑色L码库存充足，可以直接为您换成M码，预计3天内送达。是否需要我帮您提交换货申请？"

区别在哪？ 传统LLM只能基于训练数据泛泛回答，RAG系统先检索了你的订单信息、商品库存、售后政策，再生成个性化回复。

看完上面真实场景，再来简单科普下：RAG是什么？

RAG = Retrieval-Augmented Generation（检索增强生成）

• 传统LLM：答案 = LLM(问题)

• RAG系统：答案 = LLM(问题 + 检索到的文档)

有了RAG系统后，大模型的一次问题实际上分为三步执行：

（1）用户提问时，先从知识库里检索相关文档

（2）把检索到的文档和问题一起喂给LLM

（3）LLM基于这些文档生成回答

上面真实场景具体三步执行如下：

用户提问："我上个月买的羽绒服，尺码偏大想换小一号，怎么办？"        ↓【Query理解】├─ 时间范围："上个月" → 2024年10月1日-10月31日├─ 商品信息："羽绒服"├─ 问题描述："尺码偏大"└─ 用户需求："换小一号" = 换货需求        ↓【多路检索阶段】├─ 向量检索（语义理解）：│   "尺码偏大想换小一号" = "换货" = "退换" = "尺码不合适"│   召回：售后政策文档、换货流程、尺码指南│├─ BM25检索（关键词匹配）：│   匹配："羽绒服"、"换"、"尺码"│   召回：商品相关文档│└─ 结构化查询（用户数据库）：    WHERE user_id=当前用户 AND           purchase_date BETWEEN '2024-10-01' AND '2024-10-31' AND          product_name LIKE '%羽绒服%'    结果：订单号123456，10月5日购买黑色L码羽绒服        ↓【混合召回结果】（10个候选文档）├─ 订单记录：用户10月5日购买XX品牌黑色L码羽绒服├─ 商品信息：该羽绒服有S/M/L/XL四个尺码├─ 库存信息：黑色M码当前库存30件├─ 售后政策：支持7天无理由退换，需吊牌完好├─ 换货流程：在线提交申请，3个工作日审核├─ 物流信息：同城3天达，异地5-7天├─ 尺码对照表：L码胸围110cm，M码胸围106cm├─ 用户评价：该商品尺码偏大，建议拍小一号├─ 退换条件：商品未洗涤、未穿着、吊牌完整└─ 客服话术：主动询问用户需求，提供解决方案        ↓【Rerank重排序】根据Query相关性打分，精选Top3：  [文档1] 订单记录 - 相关度0.95（直接命中用户订单）  [文档2] 售后政策 - 相关度0.92（回答"怎么办"）  [文档3] 库存信息 - 相关度0.89（确认M码有货）        ↓【构造Prompt】系统角色：你是阿里巴巴淘宝智能客服助手，需要基于检索到的信息提供个性化服务参考信息：  [文档1] 用户于2024年10月5日购买XX品牌羽绒服，黑色L码，订单号123456，         订单状态：已收货（10月8日签收）  [文档2] 该商品支持7天无理由退换货政策（从签收日起算），需要商品吊牌完好、         未穿着、未洗涤。换货流程：在线提交申请→客服审核→寄回商品→发出新商品  [文档3] 该商品当前库存状态：黑色M码库存充足（30件），预计3天内可发货；         黑色S码库存2件用户问题：我上个月买的羽绒服，尺码偏大想换小一号，怎么办？输出要求：1. 基于参考信息回答，不要编造2. 主动提供具体解决方案（不是泛泛的政策介绍）3. 确认用户需求，询问是否帮助办理4. 语气友好、专业        ↓【LLM生成回答】"您好，查询到您10月5日购买的XX品牌羽绒服（订单号123456），该商品支持7天无理由退换。由于您购买的黑色L码库存充足，可以直接为您换成M码，预计3天内送达。是否需要我帮您提交换货申请？"        ↓【答案优势分析】✓ 个性化：准确找到用户的订单（10月5日）✓ 准确性：确认了政策（7天无理由）和库存（M码有货）✓ 可操作：给出具体方案（换M码）和时效（3天）✓ 主动服务：询问是否帮助办理，而非让用户自己去找

二、RAG关键技术有哪些？

通过上面真实场景，科普完RAG是什么？如果大家没有编程经验，对RAG三步执行估计比较懵。接下来通过RAG关键技术深度解析来让大家更深入理解。

1. Embedding和向量检索：RAG的核心

什么是Embedding？把文本转成一串数字（向量），让计算机能"理解"语义。​​​​​​​

"羽绒服" → [0.2, 0.8, 0.1, ..., 0.5]（768个数字）"冬装外套" → [0.3, 0.7, 0.2, ..., 0.4]"苹果手机" → [0.9, 0.1, 0.8, ..., 0.2]

如何进行向量检索？简单说就是给两个向量的"相似程度"打分，例如用余弦相似度计算两个向量的相似度。

• "羽绒服" vs "冬装外套" = 0.85（很相似）

• "羽绒服" vs "苹果手机" = 0.12（不相关）

为什么需要向量检索？语义相近的内容，其向量在空间中的位置也更接近，这样向量检索能快速找到“相似”内容，而不是机械地匹配“相同”的关键词。

• 传统关键词：用户搜"防寒衣物"，找不到"羽绒服"（词不同）

• 向量检索：能理解"防寒衣物"和"羽绒服"语义相近，成功匹配

为什么是768维？阿里这种百万级商品文档场景，768维是性价比最优解。

• 维度越高，表达能力越强，但计算越慢、越占存储

• 768维：BERT系列（BGE、M3E），中文场景够用

• 1536维：OpenAI text-embedding-3，更精准但成本高

2. 文档切分：看似简单，实则决定成败

为什么要文档切分（Chunk）？为了在精度与上下文之间取得平衡，既能精准定位相关信息，又能为模型提供语义完整的上下文。

（1）LLM上下文限制：GPT-4约8K tokens（约6000字），不能把整本手册都塞进去

（2）精准定位：一份50页的售后政策，只有第3页回答了用户问题，其他是干扰

（3）检索效率：小块匹配更精准

如何进行Chunk大小的权衡？核心是在检索精度与上下文完整性之间找到最佳平衡点。

Chunk大小	优点	缺点	适合场景
小（100-300字）	检索精准	上下文不完整，容易断句	FAQ、问答对
中（500-1000字）	平衡	通用	技术文档、产品手册
大（1500+字）	上下文完整	噪声多、检索不精准	长文章、分析报告

什么是Overlap？Overlap为什么很重要？Overlap是指在对文档进行分块（Chunk）时，相邻文本块之间的重叠部分。适当Overlap可以防止语义切断，从而提高检索召回率。

例如售后政策文本："商品自签收之日起7天内支持退换货"​​​​​​​

from langchain.text_splitter import RecursiveCharacterTextSplittertext_splitter = RecursiveCharacterTextSplitter(    chunk_size=500,      # 中文约250字，相当于1-2个段落    chunk_overlap=50,    # 10%重叠，确保关键句不被切断    separators=["\n\n", "\n", "。", "！", "？", " ", ""]  # 优先按段落、句子切分)

（1）不加Overlap，切断了关键句。

• Chunk1："商品自签收之日起7天"（不完整）

• Chunk2："内支持退换货"（不完整）

• 结果：两个chunk都没用！

（2）加50字Overlap，关键信息完整。

• Chunk1："...商品自签收之日起7天内支持退换货..."（完整）

• Chunk2："...7天内支持退换货，需保持吊牌完好..."（完整）

• 结果：关键信息被两个Chunk都包含了

常见的Overlap配置：一般建议Overlap为Chunk size的10%-20%

Chunk Size	Overlap	Overlap比例	适用场景
500 tokens	50 tokens	10%	短文档、结构清晰
1000 tokens	200 tokens	20%	通用场景（推荐）
2000 tokens	400 tokens	20%	长文档、复杂内容

3. 混合检索：1+1>2的组合拳

什么是混合检索（Hybrid Search）？为什么需要混合检索？混合检索（Hybrid Search） 是指结合多种检索方法来提高RAG系统的检索质量，最常见的是结合向量检索（语义检索）和关键词检索（如BM25）。

例如上面真实场景：用户问"订单号123456的物流信息"

• 纯向量检索（Dense Retrieval）：匹配到"订单查询"相关文档，但不是这个订单

• 纯关键词检索（Sparse Retrieval，如BM25）：精确匹配"123456"，但不理解"物流"="快递"="配送"

• 混合检索： 既语义理解，又关键词匹配，找到订单123456的物流文档

什么时候必须用混合检索？下面这些场景必须用混合检索：

• 文档包含大量专有名词（产品名、人名、技术术语）

• 用户查询包含精确信息（版本号、日期、ID等）

• 需要高召回率的场景（客服、法律文档）

向量检索（语义检索）和关键词检索（如BM25）的权重怎么选？权重不是随便定的，需要根据业务场景调优。

场景	向量权重	关键词权重
通用知识问答	0.7	0.3
技术文档检索	0.5	0.5
产品手册查询	0.4	0.6
代码搜索	0.3	0.7

例如阿里的商品搜索：可能是0.5/0.5，因为既要理解"防寒衣物"（语义），又要匹配"羽绒服"（关键词）​​​​​​​

from langchain.retrievers import EnsembleRetriever# 向量检索器vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 10})# BM25关键词检索器bm25_retriever = BM25Retriever.from_documents(chunks)# 混合检索：70%语义 + 30%关键词ensemble_retriever = EnsembleRetriever(    retrievers=[vector_retriever, bm25_retriever],    weights=[0.7, 0.3]  # 根据业务A/B测试调优)

4. 知识图谱检索：理解实体间的关系网络

什么是知识图谱检索（Knowledge Graph Retrieval）？为什么需要它？知识图谱检索是指通过构建实体及其关系的图结构，让RAG系统不仅能检索到相关文本，还能理解实体之间的关联关系，从而提供更准确、更完整的答案。

传统向量检索只能找到"相似"的文本片段，但无法理解实体间的复杂关系。而知识图谱由三个核心元素构成：实体(Entity) - 关系(Relation) - 属性(Attribute)，通过结构化的知识图谱表示，捕捉数据中实体、关系及全局语义，从而增强LLM的推理能力，解决传统RAG在复杂查询和多跳推理中的局限性。

• 复杂查询：利用社区聚类（如Leiden算法）生成分层摘要，支持跨文档主题分析（如“近五年AI研究趋势”），实现全局语义理解，解决复杂查询。

• 多跳推理：通过图谱路径回答需多次关联的问题（如“A事件如何间接导致C结果”）。

什么时候必须用知识图谱检索?

下面这些场景中,知识图谱检索能显著提升RAG效果。

场景	为什么需要知识图谱	示例
多跳推理	需要通过多个关系推导答案	"我朋友的朋友是谁?"需要跨越2层关系
产品对比	需要同时提取多个产品的相同属性	"对比三款手机的电池续航"
故障诊断	需要通过症状→原因→解决方案的因果链	"电脑蓝屏→内存故障→更换内存条"
合规检查	需要追溯政策依据链	"该操作是否合规?"需要检查多层政策关系
个性化推荐	需要理解用户历史行为和产品关联	"购买了A的用户还喜欢B和C"

5. Rerank重排序：最后一道质量关卡

什么是Rerank重排序？为什么需要重排序？Rerank(重排序) 是在初步检索后，使用更精细的模型对候选文档重新打分和排序，确保最相关的内容排在最前面，提供给LLM生成答案。

（1）初步检索返回了10个文档，但相关性参差不齐

• 向量检索：返回了语义相似但不精确的文档

• 关键词检索：匹配到了关键词但上下文不对

• 知识图谱：找到了相关实体但不是用户真正想要的

（2）所以进行两阶段检索，Rerank按相关性重新排序

• 粗排：向量检索从100万 → Top100

• 精排：Rerank从Top100 → Top3

Rerank的核心原理是什么？Rerank模型与初步检索模型的区别如下

对比维度	初步检索(First-stage)	Rerank(Second-stage)
模型类型	双塔模型(Bi-Encoder)	交叉编码器(Cross-Encoder)
计算方式	查询和文档分别编码,计算相似度	查询和文档联合编码,深度交互
速度	快(毫秒级),可预计算文档向量	慢(百毫秒级),必须实时计算
准确性	中等,适合海量召回	高,适合精排Top-K
候选规模	百万级→Top100	Top100→Top5

from langchain.retrievers import ContextualCompressionRetrieverfrom langchain.retrievers.document_compressors import CohereRerank# Rerank模型compressor = CohereRerank(    model="rerank-multilingual-v2.0",    top_n=3# 最终返回3个最相关文档)# 组合：先向量检索Top10，再Rerank精选Top3compression_retriever = ContextualCompressionRetriever(    base_compressor=compressor,    base_retriever=vector_retriever)

为什么大厂LLM算法工程师需要深入理解RAG？因为他们需要的不是会调API的人，而是能优化全链路、解决生产问题的工程师。RAG不是简单的"检索+生成"，而是一套完整的系统工程。

• Embedding：理解语义的基础，768维是平衡点

• Chunk：500字+50字overlap，保证语义完整

• 混合检索：语义+关键词，权重根据业务调优

• 知识图谱检索：理解实体间的关系网络

• Rerank：两阶段检索，精度的最后一道质量关卡

 AI大模型从0到精通全套学习大礼包

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

只要你是真心想学AI大模型，我这份资料就可以无偿共享给你学习。大模型行业确实也需要更多的有志之士加入进来，我也真心希望帮助大家学好这门技术，如果日后有什么学习上的问题，欢迎找我交流，有技术上面的问题，我是很愿意去帮助大家的！

如果你也想通过学大模型技术去帮助就业和转行，可以点扫描下方👇👇
大模型重磅福利：入门进阶全套104G学习资源包免费分享！

01.从入门到精通的全套视频教程

包含提示词工程、RAG、Agent等技术点

​

02.AI大模型学习路线图（还有视频解说）

全过程AI大模型学习路线

​​

03.学习电子书籍和技术文档

市面上的大模型书籍确实太多了，这些是我精选出来的

04.大模型面试题目详解

05.这些资料真的有用吗?

这份资料由我和鲁为民博士共同整理，鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位，在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利，同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。

所有的视频由智泊AI老师录制，且资料与智泊AI共享，相互补充。这份学习大礼包应该算是现在最全面的大模型学习资料了。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

智泊AI始终秉持着“让每个人平等享受到优质教育资源”的育人理念‌，通过动态追踪大模型开发、数据标注伦理等前沿技术趋势‌，构建起"前沿课程+智能实训+精准就业"的高效培养体系。

课堂上不光教理论，还带着学员做了十多个真实项目。学员要亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事‌！

如果说你是以下人群中的其中一类，都可以来智泊AI学习人工智能，找到高薪工作，一次小小的“投资”换来的是终身受益！

应届毕业生‌：无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。

零基础转型‌：非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界‌。

业务赋能 ‌突破瓶颈：传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型‌。

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓