加餐2 后两章课后题答案

你好，我是叶伟民。

到今天为止，课程后两章的内容即将更新完毕。和之前一样，这次加餐我会把后两章的思考题答集中发布，供你参考。

中级篇打造工单辅助系统

Q：即使在中文里面，同一个事物在不同的方言里面也有不同的叫法，如何解决这个问题呢？

A：我们可以使用某个嵌入模型再加上该方言对应的数据进行微调，得出该方言的嵌入模型。如前文所述，微调和RAG并不冲突，可以一起结合使用。

Q1：增删改查数据的时候，为什么不直接选择 LangChain 里提供的 pgvector API，而是使用 SQL 语句完成呢？

A1：因为前面提到，工具选择上我曾经从FAISS换成Milvus和PostgreSQL，其中一个很重要的原因就是FAISS没有提供图形化管理工具来管理，操作起来很不方便。

为此，我不得不在Jupyter里面使用LangChain来操作FAISS的数据。如果使用LangChain对应pgvector的API来增删改查数据，那我仍然要再Jupyter里使用LangChain来操作pgvector，那意义何在？

而使用SQL语句来增删改查数据，就可以在图形化管理工具pgadmin里面直接进行测试，这样方便很多。我的口号是——能用图形化界面解决的，就不要用代码。

Q2：既然换一个嵌入模型就需要全部重新计算一遍向量编码，为什么要添加嵌入模型列，直接更新所有向量编码列的值不就好了吗？

A2：更新所有向量编码列的值耗时很长，中途只要有任何原因中断，你就不知道哪一行已经更新过，哪一行还没有更新，这时候就需要通过嵌入模型列的值来判断了。

Q：计算两个向量之间距离其实不止以上四种，但是为什么只列出以上四种呢？

A：理论不能脱离实际。以上四种普遍都有配套的工具支持，我们马上就可以拿来用，不需要我们从零开始编写计算代码。例如pgvector目前就只支持这四种算法。例如前面讲到的LangChain不支持负内积，那就需要自己编写计算代码。

Q：今天这节课里，我们并没有将查询参数的向量编码保存进数据库。那么是否有必要将查询参数的向量编码保存进数据库呢？如果有必要，这么做的意义是什么呢？

A：不是必要的。但是可以将查询参数的向量编码保存进数据库，这样有助于事后调试和诊断以改进检索准确性。

另外，这一章的第14和19节课思考题都是开放性问题，你可以开开脑洞，在留言区里分享你的思考。

同样，21和24节课的题目也是开放性的，所以没有提供参考答案。

以上就是这次加餐的全部内容。希望课程的课后题可以帮你加深对RAG的理解，如果有什么思考或者疑问也可以继续在留言区里和我交流讨论。