大家好，我是 Qoder 的开发工程师，我叫夏晓文。今天分享的主要内容是 Qoder 如何构建代码库理解能力，以及我们在开发过程中的一些经验总结、好的设计和核心能力。
代码库理解能力简单讲分为三部分：Repo Wiki、检索引擎以及记忆。今天主要讲解 Repo Wiki 和检索引擎的设计和原理，并演示它们在真实用户场景下起到的作用。
用户关注的核心问题
下图是我们收集到的关于 Qoder 工程理解功能用户问得比较多的问题，后续的讲解会围绕这几个问题展开，主要包括 Repo Wiki 和检索功能的一些细节疑惑，以及用户关注度比较高的安全问题——源代码会不会上传到服务器。
系统架构与核心组件
Qoder 的 AI 功能很多，包括问答区的 Agent 模式、智能体模式、代码生成、NES、Quest（分为本地模式和远程模式）。虽然功能多，但 AI 这一块万变不离其宗，核心还是上下文和工具。
Qoder Agent 的系统架构分为：
- 上下文引擎：包括上下文摘要、工程结构、上下文卸载、上下文缓存等；
- 工具引擎：包括代码检索、记忆、代码修改、网络访问等命令。
用户可选模型有很多种，近期上线了新版本，支持 Ultimate 模型。在用户看不到的地方，我们还有很多专用模型，比如 Embedding 模型用于向量检索，Rerank 模型，以及今天要讲的内容中用到的专有模型。
三大核心功能：Repo Wiki、检索引擎、记忆
Qoder 的代码库理解能力有三个核心功能：Repo Wiki、检索引擎以及记忆。
- Repo Wiki
Repo Wiki 能够把代码库中的隐性知识显性化，挖掘一些暗知识，也会总结架构级的知识，并落成 Wiki 文档。背后有专门的大模型做总结。 - 检索引擎
检索引擎是专门增强设计过的，尽可能收集代码库中隐性的或结构化的代码、内容或知识，让 AI 更懂复杂的工程。 - 记忆系统
记忆是一个全生命周期的记忆管理，涵盖开发者个性偏好、经验总结以及项目知识。
核心功能一： Repo Wiki
Repo Wiki 有几个核心能力：代码可视化、知识共享以及知识沉淀。
代码可视化是用户体感最明显的一块。只要下载过 Qoder，在侧边栏就能看到按钮，点开就可以为整个工程创建知识文档。这个文档总结得比较详细，用户反馈非常好。
Repo Wiki 还支持导出整个文档，可以分享给团队其他同学。近期已经支持在检索引擎中搜索到 Wiki 的知识点。
大家常问的一个问题是 Repo Wiki 和 Deep Wiki 的差别是什么？
我们的 Repo Wiki 不只是做代码可视化、知识共享或挖掘隐性知识，还会让它参与到解决用户真实问题的过程中。在用户问答时搜索，也能搜到 Wiki 的相关文档。这些总结性文档知识密度更高，抽象程度或架构层面的隐性知识更多，对于复杂场景或需要架构知识的场景能起到非常好的作用。
核心功能二：检索引擎
检索引擎是 Qoder 工程理解里非常核心的能力。
Qoder 的检索引擎包括了几个重要的部分：语义检索、关键字检索、代码图检索、Repo Wiki 的暗知识检索，以及马上要上线的 Git历史检索。
语义检索
我们的语义检索是放在了服务端的，服务端有极高的并发和处理速度，每秒可处理数千文件，能够支撑百万甚至千万的 codebase 处理。我们也使用了定制的 Embedding 模型来提升我们的检索效果。
我们服务端只会存储代码块的向量数据，向量数据其实就是一组数字，这组数字只会反映语义相关性，所以用户大可以不用担心会有源码泄漏的安全问题。另外为了保护用户的源代码，在数据传输的任何过程中我们均使用了混淆、非对称加解密等策略保障用户数据安全。
实时更新的向量索引
我们使用了一套基于 Merkle Tree 的机制，来实现快速感知服务端和客户端的差异化。这套机制跟 Git 原理很像。Git 有提交历史，如果修改其中一个提交，后续所有提交的 Commit ID 都会变。这就是 Merkle Tree 的典型特性——完整性校验算法：任意一个叶子节点的变动，都会反映到它路径上的节点哈希或根哈希上。
一个k8s库的文件树的数据量有5 MB，如果每次比对都需要传递5 MB数据，那服务端压力会非常的大。使用 Merkle Tree 机制，只需要通过 root hash 递归比对客户端和服务端的文件hash，就能快速找到差异的文件。
在现在线上服务中，每次递归查找的成本都很低，QPS 很少，服务端压力很小，期间传递的数据只有几十上百个字节，远远低于 k8s 库需要的 5 MB 数据。在我们这套机制下，每次做增量同步只需要几十上百个字节，QPS 也少了很多，服务端资源占有极少。这是我们能做到实时增量处理的关键能力之一。
图索引与融合搜索
检索引擎分了好几个部分，其中一个是图索引，这也是我们的核心能力之一。
每次用户打开新工程，我们会自动为该工程的代码结构建一个图索引，反映函数、变量、模块之间的调用关系以及被调用关系。这个图索引会跟语义索引、Repo Wiki、关键字搜索的结果做融合搜索，得到最好的答案。
另外，图索引的数据是存储在用户的本地目录的。
核心功能三：记忆
记忆不仅仅是用来迎合个人喜好的，还包括历史经验的总结和项目知识。
个人偏好
用户可能发现模型好像一直在学你。如果你是一个喜欢表扬别人的人，在表扬模型的过程中，模型会把你的个人偏好落成记忆，存到电脑本地，变成你的个人偏好记忆。后续提问时，模型的行为会越来越像你、越来越懂你。
错误排查经验
比如你的电脑没有装 ModelJS，或者装的版本比较新或比较老。当你运行新代码时，可能需要给老版本添加一些新参数才能跑起来。我们会把这个错误排查方案落成记忆。下次你执行相同行为时，模型就知道上次跑错是因为版本问题，会按照上次的解决办法同样解决当前问题，这是一个宝贵的历史经验。
项目知识
你问了一个工程知识问题，模型发现解答效果不错，就会自动把它存成记忆。比如当前工程依赖哪些外部库，编译运行需要哪些命令。这些都是宝贵的经验，会以流程表形式存下来，下次让你运行工程时，它就能一次跑起来，不需要你再次试错。
全生命周期管理
在记忆流程里，我们还会做自动化技术评估或记忆重新组织的过程，踢掉不好的记忆，保留真正有价值、能在解答问题中起作用的记忆。
总结
总的来讲，我们如何做到工程理解？分三部分：记忆、检索引擎、Repo Wiki。
我们着重讲解了 Repo Wiki 和检索引擎的设计。Repo Wiki 不只是用来展示、总结文档或做分享，而是实实在在参与用户问答或 Agent 解决问题的过程，这也是我们跟其他产品不一样的地方。
Qoder 的检索引擎是一个相对复杂的设计，包含语义向量检索、关键字检索、图检索、RepoWiki知识检索等，通过检索结果的智能融合，为开发者提供符合意图的结果。
值得强调的一点是：源代码肯定不会放在 Qoder 的服务器上，大家可以放心。
最后我们还准备了一个手动实操文档，大家感兴趣可以上手做做看：
