轻云听书app
17.87MB · 2025-10-15
今天学点啥？每天10分钟，拆解一个真实岗位JD，搞懂一个大模型技术点。
今天拆解的是阿里巴巴智能信息事业部的LLM算法岗，薪资给到了40-70K·16薪（年薪最高112万），JD中的技术要求如下：
在阿里这个70K的算法岗中，RAG被多次明确提及，足见其重要性。
想深入了解RAG是什么？我们先看一个真实场景：
你在淘宝问客服："我上个月买的羽绒服，尺码偏大想换小一号，怎么办？"
区别在哪？ 传统LLM只能基于训练数据泛泛回答，RAG系统先检索了你的订单信息、商品库存、售后政策，再生成个性化回复。
看完上面真实场景，再来简单科普下：RAG是什么？
RAG = Retrieval-Augmented Generation（检索增强生成）
有了RAG系统后，大模型的一次问题实际上分为三步执行：
（1）用户提问时，先从知识库里检索相关文档
（2）把检索到的文档和问题一起喂给LLM
（3）LLM基于这些文档生成回答
上面真实场景具体三步执行如下：
二、RAG关键技术有哪些？
通过上面真实场景，科普完RAG是什么？如果大家没有编程经验，对RAG三步执行估计比较懵。接下来通过RAG关键技术深度解析来让大家更深入理解。
"羽绒服" → [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]
如何进行向量检索？简单说就是给两个向量的"相似程度"打分，例如用余弦相似度计算两个向量的相似度。
为什么需要向量检索？语义相近的内容，其向量在空间中的位置也更接近，这样向量检索能快速找到“相似”内容，而不是机械地匹配“相同”的关键词。
为什么是768维？阿里这种百万级商品文档场景，768维是性价比最优解。
为什么要文档切分（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 RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500, # 中文约250字，相当于1-2个段落
chunk_overlap=50, # 10%重叠，确保关键句不被切断
separators=["nn", "n", "。", "！", "？", " ", ""] # 优先按段落、句子切分
)
（1）不加Overlap，切断了关键句。
（2）加50字Overlap，关键信息完整。
Chunk Size
Overlap
Overlap比例
适用场景
500 tokens
50 tokens
10%
短文档、结构清晰
1000 tokens
200 tokens
20%
通用场景（推荐）
2000 tokens
400 tokens
20%
长文档、复杂内容
什么是混合检索（Hybrid Search）？为什么需要混合检索？混合检索（Hybrid Search）** 是指结合多种检索方法来提高RAG系统的检索质量，最常见的是结合向量检索（语义检索）和关键词检索（如BM25）。**
例如上面真实场景：用户问"订单号123456的物流信息"
什么时候必须用混合检索？下面这些场景必须用混合检索：
向量检索（语义检索）和关键词检索（如BM25）的权重怎么选？权重不是随便定的，需要根据业务场景调优。
场景
向量权重
关键词权重
通用知识问答
0.7
0.3
技术文档检索
0.5
0.5
产品手册查询
0.4
0.6
代码搜索
0.3
0.7
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测试调优
)
什么是知识图谱检索（Knowledge Graph Retrieval）？为什么需要它？知识图谱检索是指通过构建实体及其关系的图结构，让RAG系统不仅能检索到相关文本，还能理解实体之间的关联关系，从而提供更准确、更完整的答案。
传统向量检索只能找到"相似"的文本片段，但无法理解实体间的复杂关系。而知识图谱由三个核心元素构成：实体(Entity) - 关系(Relation) - 属性(Attribute)，通过结构化的知识图谱表示，捕捉数据中实体、关系及全局语义，从而增强LLM的推理能力，解决传统RAG在复杂查询和多跳推理中的局限性。
下面这些场景中,知识图谱检索能显著提升RAG效果。
| 场景 | 为什么需要知识图谱 | 示例 |
|---|---|---|
| 多跳推理 | 需要通过多个关系推导答案 | "我朋友的朋友是谁?"需要跨越2层关系 |
| 产品对比 | 需要同时提取多个产品的相同属性 | "对比三款手机的电池续航" |
| 故障诊断 | 需要通过症状→原因→解决方案的因果链 | "电脑蓝屏→内存故障→更换内存条" |
| 合规检查 | 需要追溯政策依据链 | "该操作是否合规?"需要检查多层政策关系 |
| 个性化推荐 | 需要理解用户历史行为和产品关联 | "购买了A的用户还喜欢B和C" |
（1）初步检索返回了10个文档，但相关性参差不齐
（2）所以进行两阶段检索，Rerank按相关性重新排序
对比维度
初步检索(First-stage)
Rerank(Second-stage)
模型类型
双塔模型(Bi-Encoder)
交叉编码器(Cross-Encoder)
计算方式
查询和文档分别编码,计算相似度
查询和文档联合编码,深度交互
速度
快(毫秒级),可预计算文档向量
慢(百毫秒级),必须实时计算
准确性
中等,适合海量召回
高,适合精排Top-K
候选规模
百万级→Top100
Top100→Top5
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CohereRerank
# Rerank模型
compressor = CohereRerank(
model="rerank-multilingual-v2.0",
top_n=3# 最终返回3个最相关文档
)
# 组合：先向量检索Top10，再Rerank精选Top3
compression_retriever = ContextualCompressionRetriever(
base_compressor=compressor,
base_retriever=vector_retriever
)
为什么大厂LLM算法工程师需要深入理解RAG？因为他们需要的不是会调API的人，而是能优化全链路、解决生产问题的工程师。RAG不是简单的"检索+生成"，而是一套完整的系统工程。
日拱一卒，让大脑不断构建深度学习和大模型的神经网络连接。
如果你想更深入地学习大模型，以下是一些非常有价值的学习资源，这些资源将帮助你从不同角度学习大模型，提升你的实践能力。
