引子不断迭代的prd做内部AI智能客服。不能把所有文档喂给大模型成本大效果差。 使用RAG技术降低90%的推理成本不胡编乱造。目录1.为什么需要RAG2.RAG的核心工作流程3.商业化落地实战痛点4.进阶方案与总结大模型通才但是不知道公司内部资料。要么幻觉回答要么回答不知道。你要是将全部资料在一个对话里高速大模型是行不通的。1.上下文窗口限制2.推理成本高昂3.相应速度慢如何做RAG retrieval 检索 augmented 增强 Genreation 生成数据准备阶段业务数据–chunking(分片)/字数/段落。通过 embeding翻译将文字翻译成向量存入向量数据库用户提问–embeding翻译–找相似向量–进行召回–召回内容限制–返回给用户实际应用痛点1.文档解析pdf格式–ocr2.颗粒度切太大噪音多。 切太小语义丢失3.检索准确率普通RAG60%RAG混合检索重排模型–90%4.用户提问的模糊性查询重写方案graphRAG. 解决实体关系复杂AgenticRAG 具备思考与拆解能力的智能体。关键数据清洗、分片策略、多路召回、工程调优RAG将产品切片用户提出问题后RAG找到相关切片和用户问题一起发给大模型RAG基本流程1.数据准备阶段分片 索引2.回答召回 重排 生成分片字数/段落/章节/页码–进行切片索引通过embeding将片段文本转换为向量 将片段文本和片段向量存入向量数据库向量:有大小有方向的量embeding:翻译官 文字转化为向量向量数据库存储和查询向量的数据库。 存储向量文本召回搜索与用户问题相关的片段。【成本低好使短准确率低–向量相似度】 初步筛选用户的问题–embeding–转换成向量—向量数据库—返回和用户问题相似的结果如何计算相似度余玄相似度夹脚欧式距离点积–10个和用户相似度相似重排cross-encoder 再挑3个相似的生成用户问题检索到的向量片段–通过大模型分析将结果发送给用户高质量文本分块为什么做1.LLM上下文长度限制2.向量检索对语义完整性的依赖。理想分块标准平衡信息密度和上下文完整性chunk_size控制大小—256/512/1024chunk_overlap保连续。 size的10%-20%策略演进路径基础分块固定长度递归字符推荐按照分割符递归切分分隔符有优先级使用大多数通用文本按句切分法律新闻。按句分割拼接小于最大块。结构感知markdown/html ,对话轮次语义/主题向量相似度LDA主题模型高级策略小-大分块、代理式分块RAG检索优化