前面我们已经做了一个最简单的版本，这种就跟老外出租屋里开发出来的软件类似，你说它不完整吧，它已经有了所有必须要有的东西，你说它完整吧，没有哪家企业线上会这么部署，所以我们还需要持续优化。

优化方向

首先我们得扩大规模，我们第一版里面文档和问题太少了，一共就10+篇文章，也都不长，所以整不出幺蛾子。我问了大模型，他给我指了一些方向，比如把GitLab的handbook整下来，还有Kubernetes的文档和Atlassian Team Playbook，这3大块文章整下来，就能玩不少事情，比如权限隔离，rerank，文档版本更新，搜索不到如何处理，等等。

然后我就先把GitLab的handbook整下来了，把这里面的文档按照之前的策略（也就每个H2和下面的文档内容算一个chunk）做拆分，然后调用百炼的embedding的模型全部转换成向量，一共花了我10块钱（不多，但也不少，因为这是一次，如果后面想要评估不同的切分策略，得切分好多次）。

做一做试试

我把embedding做好之后，搜了一个问题，“如何请病假”，这就遇到了一个问题，不同国家的规定是不一样的，如果我不提前收集好用户的国家信息，搜索出来的结果就会有很多国家相关材料排到了前面。这其实不是我们想要的结果。

Query Analysis

上面这个其实是一个常见的问题，专业名词叫Query analysis。就是用户提问之后，我们回答用户问题之前，可能需要询问用户来收集额外的信息（当然也可以通过别的方式收集，收集不到再找用户问）。

按照ChatGPT教我的，这个Query Analysis实现的时候，可以多种方法组合实现，这样的效果是最好的，而且想要做这个，我们得提前熟悉我们要做RAG的材料，比如既然是要分国家查询病假，那是不是还有别的类似问题要知道国家，或者知道用户性别，年龄等等信息？都哪些问题需要知道这些信息呢？我们需要提前把这些信息整理一下。再或者是我们做个智能客服，用户问他的xx订单状态不正确，这个时候我们就需要用到tool calling（这个概念我还没深入学习，但我知道有这个概念），我们要先调用数据库把对应的信息查出来，然后再调用大模型去给用户解答。

材料准备

由于GitLab的这些handbook实在是太多了，我的目的是学习RAG而不是做真实的系统，所以这里我先把需要国家信息的这个问题解决下，然后后面再遇到别的问题再去解决就好了。

如何实现Query Analysis

不能做硬编码

最开始ChatGPT教我去判断输出里面有没有sick leave, leave, 病假，等等这样的词。但我一想就不对啊，因为语言里面很容易改写，绕过这些关键词，但意思还是那个意思。比如“我身体不舒服，应该如何请假？”。再或者用日语提问呢？

intent classification

我们想要的其实是判断用户的意图，这样的话我们就可以准备一些问题，然后把问题，还有用户的提问，一起喂给大模型，看用户是不是在问这些问题。比如下面的问题：

• 这个问题到底是不是 HR 假期政策？
• 这个问题到底是不是关于如何请病假的问题？
• 用户是否已经提供国家？

confidence

大模型的这个intent classification也不是100%可靠的，所以我们可以让大模型给我们返回confidence，如果confidence过低，就不要去硬答，而是去追问用户，他到底是想问啥，然后再去看如何回答。

Query rewrite

我知道有这个概念，而且rewrite之后，能提升回答答案的准确度，但详细的情况我还没来得及学习，这个留到下次学习。

ChromaDB有没有GUI

我现在是学习阶段，所以选择了ChromaDB，这样我能专注于RAG的整个流程，而非向量数据库的各种细节。但我有时候也会好奇数据库里面存储的信息对不对，那他有没有对应的GUI工具呢？

答案是有的，但我们得先本地启动一个服务，然后GUI才可以读取数据。比如可以用这个工具：chroma-ui

兜底检索

我在做的时候，遇到的就是我检索的时候，如果用户提问的问题是需要国家和entity等信息的，我就直接问出来然后再让大模型去回答。但这个会过滤掉一些答案（正确答案），比如还是上面的问题，“我有几天病假”，RAG问我是哪个国家的，我告诉他中国，然后他就拿着country_code=CN去检索，而正确答案是在general里面（也就是没有country_code）。所以他的回答并不好。但是加上兜底检索之后就找到了正确答案：