在之前的技术开发中，从经验来看只要流程正确了基本上结果也是正确的，但这个经验放到大模型开发上发现好像不是那么回事。
以作者手中目前的项目来说，刚开始作者在做这个项目的时候总觉得功能特别简单，很容易就做出来了；然后等做了一段时间之后才发现好像没有那么简单，想做出来好像很容易，但想做好真的很难。
之后，在业务需求稳定下来之后作者也用了很多方法去优化系统，但发现效果虽然变好了一点，但好像也没有那么好，并没有达到用户的要求。
所以，经过上周连续的加班之后，效果要比之前好了很多；但现在回头看看其实优化点也并不是特别多，并且在流程上改动也不是特别大，主要问题基本上都集中在提示词上面，以及部分的思路问题。
在上篇文章中介绍了这次的技术架构上的调整，但在调整之后进入具体开发时，作者把之前的优化方法和手段都用到了新的架构上；但这里也遇到了一个问题，好像流程上都是对的；但结果上好像也没有达到想要的效果。
所以，这时作者就在思考一个问题，到底是什么原因导致的？
然后就发现了两个问题，一个是提示词；另一个是思路问题，不知道在合适的环节选择合适的技术，而只是简单的把之前的思路照搬过来。
首先来说一下提示词的问题，在大模型应用中提示词是重中之重，一个好的提示词能解决大部分问题；并且很多时候效果不好的原因就是你提示词写的太拉垮了。
说实话作者个人并不擅长写提示词，甚至很多时候面对一个新的业务场景都不知道应该怎么写好一个提示词；大部分情况下都是把要求业务需求罗列到提示词中，然后再交给模型，让模型帮忙优化一下。
但提示词既然被称为提示词工程，还是有一定的原因的，那就是写提示词有一套具体的方法，针对不同的业务场景有不同的提示词模板和方式。提示词既要写的严谨，格式清晰，还要写的简单易懂，足够的泛化，否则很容易出现模型训练中的过“拟合”状态。
而关于思路问题，一是需要在不同的业务中选择合适的技术架构，毕竟单纯的从技术角度来说，其实大模型应用开发的技术栈并不多，也不复杂，主要还是一个思路问题和理解问题。
在刚开始做问数功能时，直接开发了一个检索工具， 把元数据作为查询条件，用户问题作为相似度检索参数，对知识库进行标量检索和混合检索；但发现检索的效果并不是很好。
但从测试的过程来看，用户一般会使用模糊查询的方式，比如说某某地区某个部门的什么数据，或者说某个地区某个部门的具体数据；而这样就可以通过把地区，部门和什么数据作为检索条件进行查询；并且把什么数据这个参数作为非必填项，这样就可以让模型理解用户的问题。
如果有具体的数据名称，那么就使用标量(条件查询)，如果没有具体的名称，那么就使用向量进行模糊查询，这样既提升了召回率，也提升了精准度。
总之，大模型应用开发不仅仅是一个技术问题，更多的是经验和思路问题；当然，提示词工程能力也很重要，毕竟提示词是模型应用的基础。
