在最初设计BIC-QA的时候，我想把产品定位为不会胡说八道的知识库。因此对数据召回搞得很严格，提问质量不高，或者提问不够准确，就经常会返回无法匹配到知识库。后来和同事以及一些朋友交流后，他们觉得如果总匹配不到知识，那么别人来使用知识库的人就会觉得这个知识库没啥用。
于是我就面临两难的选择，如果有人的提问质量不高，我们无法匹配到知识怎么办？调低匹配度的参数？Rerank的时候放宽召回条件？经过这么调整之后，一些“不太好”的问题也能够返回结果了。不过另外一个问题出现了，答案的针对性就下降了很多。最终我们还是选择宁可不回答问题，也尽可能让答案更加准确，因为绝大多数的用户使用知识问答是为了准确地找到答案，而不是想泛泛地提问，从而找到一些思路的。
想要十分准确地回答用户的提问难度很大，这是为什么呢?实际上我们目前常用的RAG方法都不是基于语义的，而是基于向量匹配的。很多朋友可能觉得向量数据库是实现专业或者私有知识库的关键，因此会错误地认为向量搜索是可以识别语意的，其实这是做知识库一个极容易踩坑的地方。向量检索实际上是一个数学问题，最朴素的原理是向量距离、余弦距离等。
我们通过向量计算只能获得相似度等指标，无法真正实现语义理解。向量搜索的核心思想是将现实世界中如文本、图片、音频、视频、用户行为等通过某种AI模型（如Embedding模型）转换成数学上的高维向量，然后通过计算向量之间的“距离”或“相似度”，在庞大的向量库中快速找出与目标向量最相近的Top-K个结果。但是我们使用向量检索的目的并不是找到Top-K的结果，而是召回某个向量所指向的某段文字资料。向量检索的相似度与你的问题很高，并不代表召回的文字资料就是回答问题所需要的资料。
想要提高知识问答的质量，有几种方法，第一种是增加知识库的条目，让问题能够命中你的知识条目，从而获得准确的回答，这种方法最为朴素，但是成本极高，需要你对专业知识极其了解，并且拥有巨大的知识库才能做到；第二种方法是多种召回手段并用，采用极其暴力的算法去完成多路召回，然后再去做重排，最终召回与问题相关性最高的回答，这种方法需要你对知识库进行精心的设计，并且构建多种召回路径的知识体系，甚至使用一些知识图谱的手段来增强召回的准确性；第三种方法是优化问题，在提问之前对问题进行补全、加工、意图理解等，让问题变得更加有针对性，从而提高问答的质量。
目前BIC-QA只是在知识库上做了优化，第二第三种手段尚未使用，在未来我们将会逐步增加这方面的能力。不过语义理解的相关计算的算力要求比较高，反馈延时也比较长，目前我们采用的服务端轻量级算力是无法实现的。另外一方面，复杂的服务器端的语义识别意味着响应速度的大幅下降，响应延时又与服务资源紧密相关，对于目前这个公益项目，我们还无法承受这种业务负载。后续我们可能会优化客户端，在端侧做语义识别，端侧模型能力比较强的使用者可以开启本地增强意义识别功能。不过也不排除今后有钱了，我们会在这方面投入更多的资源，更好地把这个公共知识库做好。
