1.ƻ?苹果???λԴ??
2.利用好 git bisect 这把利器，帮助你快速定位疑难 bug

ƻ?定位s定???λԴ??

       深入分析Dify源码：大模型调用异常定位

       在使用Dify服务与Xinference的THUDM/glm-4-9b-chat模型部署时，遇到了知识库检索节点执行时报错大模型GPT3.5不存在的源码问题。异常出乎意料，位原因为没有额外信息可供进一步定位。苹果

       通过源码和服务API调用链路的定位s定设计logo的源码分析，我们发现问题的源码关键在于知识库检索的实现。该功能在api/core/rag/datasource/retrieval_service.py中，位原其中混合检索由向量检索和全文检索组成。苹果我们关注了关键词检索、定位s定向量检索和全文检索这三个基础检索方式：

       关键词检索：仅使用jieba进行关键词提取，源码无大模型介入。位原mybatis源码笔记

       向量检索：通过向量库直接搜索，苹果如Milvus，定位s定无大模型调用。源码

       全文检索：使用BM，大部分向量库不支持，实际操作中返回空列表。

       问题出现在知识库检索节点的多知识库召回判断中，N选1召回模式会调用大模型以决定知识库。在配置环节，前端HTTP请求显示配置错误，使用了不存在的libc源码解读GPT3.5模型。

       经测试，手工创建的知识库检索节点使用了正确的glm-4-9b-chat模型，问题出在默认模板的配置上，即N选1召回模式默认选择了GPT3.5。本地部署时，如果没有配置相应模型，会导致错误出现。

       总结来说，解决方法是修改默认模板，将知识库检索的默认模式改为多路召回，这样可以避免新手在本地部署时遇到困扰。hashmap源码汇总建议Dify官方在模板中改进这一设置，以简化用户部署流程。

利用好 git bisect 这把利器，帮助你快速定位疑难 bug

       利用好 git bisect 这把利器，帮助你快速定位疑难 bug

       使用git bisect二分法定位问题的基本步骤：

       1. git bisect start [最近的出错的commitid] [较远的正确的commitid]

       2. 测试相应的功能

       3. git bisect good 标记正确

       4. 直到出现问题则 标记错误 git bisect bad

       5. 提示的commitid就是导致问题的那次提交

       问题描述

       我们以 Vue DevUI组件库的一个bug举例子

       5dcb这一次commit，执行yarn build报错，报错信息如下：

       我可以确定的是上一次发版本（ dce4）是可以build成功的。

       git bisect 简介

       git bisect命令使用二分搜索算法来查找提交历史中的哪一次提交引入了错误。它几乎能让你闭着眼睛快速定位任何源码导致的问题，非常实用。

       你只需要告诉这个命令一个包含该bug的暴力捉妖源码坏commit ID和一个引入该bug之前的好commit ID，这个命令会用二分法在这两个提交之间选择一个中间的commit ID，切换到那个commit ID的代码，然后询问你这是好的commit ID还是坏的commit ID，你告诉它是好还是坏，然后它会不断缩小范围，直到找到那次引入bug的凶手commit ID。

       这样我们就只需要分析那一次提交的代码，就能快速定位和解决这个bug（具体定位的时间取决于该次提交的代码量和你的经验），所以我们提交代码时一定要养成小批量提交的习惯，每次只提交一个小的独立功能，这样出问题了，定位起来会非常快。

       接下来我就以 Vue DevUI之前出现过的一个bug为例，详细介绍下如何使用git bisect这把利器。

       定位过程

       其中5dcb这次是最近出现的有bug的提交，dce4这个是上一次发版本没问题的提交。

       执行完启动bisect之后，马上就切到中间的一次提交啦，以下是打印结果：

       可以看到已经切到以下提交：

       执行命令：

       构建成功，所以标记下good：

       标记万good，马上又通过二分法，切到了一次新的提交：

       再次执行build命令：

       build失败了，出现了我们最早遇到的报错：

       标记下bad，再一次切到中间的提交：

       以此类推，不断地验证、标记、验证、标记...最终会提示我们那一次提交导致了这次的bug，提交者、提交时间、提交message等信息。

       最终定位到出问题的commit：

       github.com/DevCloudFE/v...

       整个定位过程几乎是机械的操作，不需要了解项目源码，不需要了解最近谁提交了什么内容，只需要无脑地：验证、标记、验证、标记，最后git会告诉我们那一次提交出错。

       这么香的工具，赶紧来试试吧！

       问题分析

       直到哪个commit出问题了，定位起来范围就小了很多。

       如果平时提交代码又能很好地遵循小颗粒提交的话，bug呼之欲出。

       这里必须表扬下我们DevUI的田主（Contributor）们，他们都养成了小颗粒提交的习惯，这次导致bug的提交c0c4cc1a，只提交了4个文件，涉及多行代码。

       我们在其中搜索下document关键字，发现了两处，都在drawer-service.ts整个文件中：

       一处是行的：

       另一处是行的：

       最终发现罪魁祸首就是行的代码！

       破案！

       此处@lnzhangsong我们的田主，有空麻烦修下这个bug。