如何巧妙优化llm与RAG的学习效果？

拖延症患者的RAG复盘：从入门到想放弃，再到不得不学

这是一篇拖延了半年的文章。真的，半年前我就想写这玩意儿了当时就计划写一篇的文章，不过之后事情太多有些搁置。今天终于是打算拿出来一番那个。毕竟 年初有计划做一下基于LLM大模型的应用，正好公司有业务需求，于是学习了一下RAG的相关知识，一边看字节开源的 eino 框架学习开发，一边补充这 agent，mcp，rag相关的知识。

从一个旁观者的角度看... 说实话，这过程简直像是在坐过山车。有时候觉得大模型简直神了有时候又觉得它笨得像头猪。如果你是一位没有接触过AI开发， 只局限于使用AI工具的朋友，可能会对提及的这些名词有些疑惑，可能经常看到一些新闻携带这些名词。别怕，我也经常懵。

为什么我们需要RAG？主要原因是大模型爱撒谎

RAG的提出是主要原因是大模型存在幻觉问题， 大预言模型虽然看上去万能，但其实很多时候会一本正经的胡说八道。如果是编程开发中出现这种问题，问题不大，大不了跑一下发现编译不通过重新编码。但是在医生，讼师等行业如果出现这种现象，那么就会导致严重的问题。为了解决这个问题，业界提出了RAG方法 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。

未来可期。 然后 介绍一下rag技术的基本原理.#人工智能#程序员#学习#机器学习#产品经理#转行通义千问3-Reranker-0.6B一键部署.rag 检索增强 LLM ,简单来说,就是给 LLM 提供外部数据库,对于用户问题 ,通过一些信息检索 的技术,先从外部数据库中检索出和用户问题相关的信息,然后让 LLM 结合这些相关信息....

佛系。 一开始的版本就是在与AI交互的过程中，在prompt中，特别是 role 中的 system中，写入相关知识内容，防止AI胡编乱造。但是当相关知识内容变得庞大后单纯的在prompt中内置全部资料的方法就失效了。一是模型存在上下文token限制， 过多的资料反而会导致它出现幻觉；二是出于成本考虑，如果塞入过多的资料，但是实际只用到其中的一点，那就会导致token浪费，开销过高。

向量数据库：把文字变成数字的游戏

然后就有人提出，将不同的资料都存入向量数据库。在AI需要的时候，根据我们的描述内容的向量后来啊去匹配数据库中符合的向量。简单向量就是一串数字，它像一个‘语义坐标’，代表了文本在多维空间中的位置。意思相近的文本，它们的‘坐标’在空间中也会靠得很近，求锤得锤。。

通常， 我们存储的不仅仅是文本块的向量，还会附带元数据比如文档来源，这段记录对应的实际意义。不但可以用于知识库，还可以用于各种场景类向量数据库的优化。明明向量是由数据向量出来的，却用问题的向量去匹配，这是一个需要注意的点。 盘它。 刚开始接触RAG系统的人，往往会主要原因是一开始小数据量的成功匹配，将向量匹配当成问答系统了。这样或许也可以匹配到，但是基本匹配系数比较低，当数据量增大后容易匹配出一些奇怪的数据。

太离谱了。 在向量搜索领域，主流的匹配方式分为两大流派，它们分别解决了不同类型的问题。本来想写一节谈论向量匹配的方法， 比如余弦相似度，欧氏距离，点积之类的，不过本文更多是面向开发者，所以就不多谈了还是聊一聊开发技术选型强关联的内容。向量索引，也可是一种数据库索引。不过它有很多类型。

这里随便列几个市面上常见的向量数据库， 大家看着选吧，反正选哪个都会踩坑：

数据库名称	主要特点	吐槽点/缺点	适用场景
Milvus	开源，功能极其强大，支持多种索引	部署太麻烦了组件多，学习曲线陡峭	海量数据，需要极致性能
Pinecone	全托管，不用管运维，API好用	贵！而且有时候网络不稳定	不想折腾运维的初创公司
Chroma	轻量级， Python库，安装即用	数据量一大就慢得像蜗牛	本地测试，小规模Demo
Weaviate	模块化设计，支持向量化插件	文档有时候写得让人摸不着头脑	需要多模态搜索的场景

那些让人头秃的优化技巧：从“能用”到“像个人样”

基础的RAG流程虽然简单，但在实际应用中，召回的上下文质量直接决定了LLM生成答案的优劣。为了从“能用”到“好用”，我们需要一系列的调优手段来优化召回效果。RAG的调优可以分为三个核心阶段：**预处理**、 到位。 **检索** 和 **后处理**。将文档切分成合适的、独立的语义单元是RAG中最关键的第一步。分块的质量直接影响向量的质量和检索的精度。

比如我这里有一个简历， 它的内容是 1.预期岗位go .....

向量内容： 岗位名称：go开发工程师

大体上... 如果你切分得不好，比如把“Go”和“语言”切开了那搜出来的后来啊简直没法看。一边不禁感叹，大模型从22年到如今的发展迅速。在去年的时候，更多还只是用于提示词和问答，而现在以及可以真的用于实际开发之中了。从GitHub copilot 到 cursor 到claude code。各种工具越来越可靠，越来越现代化。一边在写文档中也有了很多帮助。可以看到本文在谈到RAG调优的格式突然有些变化。主要原因是到这里笔者有些懒了手写了思路与大纲后直接让AI优化，然后再手改一番。

HyDE：用谎言去寻找真相？

用他们回答的问题对块进行索引会稍微改变问题,但有助于解决对齐问题并提高搜索相关性:我们不优化与文档的相似性,而是优化与潜在问题的相似性.当进行查询时,HyDE指示LLM生成一个假设答案。 是个狼人。 接着,无监督对比学习编码器将文档转换为嵌入向量。 该矢量用于精确定位语料库嵌入空间中的邻域,从而能够基于矢量相似性检索相似的真实文档。在第二步中,生成的文档被锚定...

这听起来很玄乎对吧？其实就是让大模型先瞎编一个答案，然后用这个瞎编的答案的向量去数据库里找真正相似的文档。虽然听起来很荒谬，但效果居然还不错。这就是所谓的“用魔法打败魔法”，挺好。。

查询转换：别让用户乱说话

用户的原始问题可能与文档中的表述存在语义鸿沟。查询转换的目的就是通过 或 用户的查询，来提升召回率。还有一种最简单的优化方法。用户提问都过一遍LLM大模型，让他标准化一些。作用:通过优化问题表述,减少因提问方式差异导致的检索偏差。

简直了。 请求转换请求转换是为了提高查询后来啊的准确性而对用户请求进行重构、优化的过程.需要注意的是,虽然这比直接查询到答案的嵌入匹配要好,但对于高度不相关的问题和上下文,产生幻觉的可能性也会更高,所以呢需要对过程进行优化,并注意这些边缘情况.

比如用户问：“怎么修那个报错？” 这时候大模型可能一脸懵。但如果先转换成：“如何修复Python中的IndexError？” 那检索效果就会好很多。增加 往白了说... 追问机制,也仅是让用户去完善自己的问题,比如针对 用户给出的查询条件不足 ,有时关键词提问,就会出现检索失败,但对关键词补充成语句,就能增加检索的成功性。

RAG-Fusion：多问几次总有一次是对的

RAG-Fusion : 让LLM去优化用户query, 输入query,丰富搜索信息后,都分别喂入LLM,获取到回复后,使用倒数排序融合 得到统一得分,重排取TOP k检索后来啊.很多开源开源LLM对上下文长度支持和语义理解相对较弱，靠谱。。

这招就是广撒网。把用户的问题 成好几个版本，全都去搜一遍，然后把后来啊混在一起重新排序。虽然费点Token，但能捞到更多有用的信息，卷不动了。。

代码与工具：乱七八糟的堆砌

对于 AI应用开发。对于模型的调用方法多种多样，不同家有不同的标准。而我们最常用，也就是各种大模型平台最经常提供的接入方式就是OpenAI标准。下面是一个使用curl调用OpenAI chat/completions接口的示例：，我们都曾是...

curl https:///v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -d '{ "model": "gpt-4", "messages": 代码实现如下:以上问题的答案是二、Long Context Reorder思路来自论文。代码实现如下所示:以上问题的答案是三、 Contextual C 马上注册LLM之RAG实战| 使用LangChain的三个函数来优化RAG ArronAI 技术 本文介绍三种Langchain提供的方法来提高RAG效果,具体如下: 一、Multi Query Retriever 代码实现如下: 以上问题的答案是 二、Long Context Reorder 思路来自论文《Lost in Middle: How Language Mo...

一言难尽。 LangChain虽然火，但是版本更新太快了文档经常跟不上，而且代码封装得太深，有时候想改点东西得钻进去看半天源码。不过它确实能省不少事。

优化一下。 这里再给个表格， 对比一下几个常用的RAG开发框架，省得大家选的时候纠结：

框架名称	核心优势	槽点	推荐指数
LangChain	生态最全，组件多，教程多	代码抽象过度，复杂项目难维护	⭐⭐⭐⭐
LlamaIndex	专注于数据索引，连接数据源方便	有些概念太学术，上手门槛高	⭐⭐⭐
Haystack	deepset出品，检索pipeline很专业	社区相对小一点，国内资料少	⭐⭐⭐
AutoRAG	自动评估和优化，懒人福音	太新了坑还没踩完	⭐⭐

可视化决策：AutoRAG Dashboard

可视化决策:运行autorag dashboard启动的监控界面里,所有实验后来啊的指标对比一目了然.第一次接触AutoRAG时,我被它 自动优化RAG pipeline 的宣传吸引,但真正用起来才发现,这工具最厉害的地方在于它的自动化评估体系.2. 优化RAG pipeline的五个实战技巧.

核心思路:通过收集用户对回答的反馈,动态优化知识库和检索流程,使系统具备自我进化能力.这听起来很美好，但实际落地的时候，哪有那么多用户给你反馈啊？大部分时候都是用户问完就走，好坏全靠猜，吃瓜。。

脑子变懒了 但活儿得干

我开心到飞起。 本文将拆解三个直击痛点的RAG优化方案,从检索、排序到查询重构,层层递进,打造能扛住真实场景的AI自动化工作流..所以呢,RAG优化方案的核心在于提升检索上下文的 信噪比 .向量搜索追求的是“快”和“广”，可能会包含一些不那么相关的后来啊。重排序则是在召回之后、生成之前，引入一个更“精”的模型，对初步召回的Top-K个后来啊进行二次排序。

ߔ�主要贡献:论文提出了一种新颖的强化学习框架Knowledgeable-r1,能够在检索增强生成任务中优化知识探索策略..ߔ�通过强化学习方法优化参数知识和上下文知识的联合采样,提升模型的推理能力..，总体来看...

基于大模型的 RAG 应用开发与优化.开发企业级LLM应用是一个复杂的过程,涉及到多个技术层面的集成与优化.

但是也有些养懒了大脑。现在遇到问题，第一反应不是去Google搜文档，而是直接问AI。虽然效率高了但总感觉少了点什么。可能这就是进化的代价吧。

本文还只是单纯的 RAG知识库，或者说向量数据库的相关技术点。下一篇就谈一谈 ai agent 与 mcp 吧。如果读者有更好的建议，可以直接在评论区留言。以上内容大概就是笔者最近在大模型学习，RAG开发与特定领域向量数据库构建业务中的一些与优化心得，我服了。。

就这样吧... 欢迎点击，评论。笔者也是探索中学，如果读者有更好的建议，可以直接在评论区留言。