大模型应用理论那么简单，为什么实现起来那么复杂？

其实理论的简单性和技术的复杂性，往往都隐藏在那些细节里。

今天闲的没事回头梳理了一下这大半年来开发过程中所遇到的问题，然后画了一个架构图；然后突然发现，这么长时间好像也没做太多东西啊，但为什么总感觉自己很忙，很累，但东西又没做好？

原因就在于技术是一项实践性很强的东西，很多时候你懂了并不代表你会了。

在真实的技术场景中，理论是解决问题的基础，但理论可以有多种不同的落地方案；因此，在技术的发展中，理论会随着技术的突破而突破，而同样的在具体落地的过程中，又会产生多种适用不同场景的落地方案。

还是以RAG技术来举例，在之前的文章有介绍过RAG的本质是一个方法论，而不是一个具体的技术栈；它更多的是一种解决方案，用来解决大模型的缺陷问题。

• 幻觉问题

• 垂直领域知识不足问题

• 知识更新不及时问题

RAG是一种方法论，而不是一项具体的技术——你真的知道什么是RAG吗？

但RAG本身并没有对技术做任何的限制，比如说使用什么样的知识库方案，使用哪种召回策略，上下文怎么处理等等；RAG本身对这些并没做任何约束，你可以根据自己的需要选择任何技术方案。

毕竟对RAG来说——检索增强生成，其核心就在于检索和增强生成；但到底怎么检索的我不管，我的目的只有一个，让大模型表现得更好。

这也是为什么很多人在做RAG开发时，明明流程上都没有问题，但结果就是不准确的原因；因为你根本没有明白，RAG的真正难点在哪里。

RAG本身的每个步骤看起来都很简单，但等你把所有流程都串起来之后就发现，好像哪哪都不对；最终的结果就是，差之毫厘，失之千里。

所以说，RAG最难的并不是把它的流程跑通，而是让它真的变得能用且好用。

unsetunset一、大模型的理论和技术很简单，难得是把效果做好unsetunset

在大多数人眼里，学习大模型技术和学习传统的技术一样，只要把技术学好就行了；但现在不得不告诉你一个残酷的事实；大模型应用技术做好要远比做出来更难。

由于模型本身的复杂性，同样的流程，不同的模型，甚至是同一个模型不同的环境，都需要进行不同的测试和优化才可能达到最优的效果。