交流交流。昨天,去泰康图书馆了。由于最近抖哥接的项目比较多,抖哥就把井兄弟摇过来了。但井兄弟有类似滑膜炎的疾病,不能天天来图书馆,有点遗憾。不过,他自己租房住,没人打扰,开发时间上应该能有保证。井兄弟来,给我带来一个变化,我编程一圈试下来,Qoder还是比较靠谱,但花费惊人。他今天来说,自己用的是chatGPT,在某宝上20块钱买的一个月,足够用了,我试了一下,效果还不错,大大的节省了我的开发成本。看来,多与人交流是非常有必要的,知识可以对齐一下,省钱省力,光靠闭门造车肯定不行,因为每个人的日常行为基本是固定的,不同的人走不同的路线,交流一下沿途风景,长长见识也好,说不定可以优化下路线,或者避下坑,何乐而不为呢?
[290]--------底部有张生活照片
【关键词】python、ragflow、专家问诊、追踪chat
描述:现在基本问询结束之后,专家问诊卡着了,需要处理一下。
开工:
20250127周一时间段:13:33-13:40
20250127周一时间段:14:10-14:20
先搞个测试用例,看看效果,可以适当的打几个断点,找到原因截图如下:

图2a-1
注:这个是因为返回的和判断的不一样,修改代码如下:

图2a-2
注:去掉括号,因为返回时不带括号。接下来,上线看下效果,看看能不能正常返回。
发现不能正常返回,卡住了,截图如下:

图2a-3
注:接下来,还要跑测试用例,打断点,找下原因。
20250127周一时间段:14:47-15:00
20250131周五时间段:14:18-14:20
20250131周五时间段:14:22-14:40
20250131周五时间段:22:48-23:00
跑下测试用例,看看效果,如下,现在代码更新,需要等一下。运行下测试用例,看看效果,测试结果如下:

图2a-4
注:确实卡住了,检查下卡住的原因,立个flag,这个问题解决不了,今晚到凌晨4点再睡,就这么愉快的决定了。
20250131周五时间段:22:59-23:00
20250131周五时间段:23:00-23:20
打几个断点看看效果,找到原因如下:

图2a-5
注:这个等了10分钟才给出结果,看看什么原因,是不是哪里卡住了。接下来,打断点测试。
20250131周五时间段:23:11-23:20
20250131周五时间段:23:30-23:40
打断点之前,先看看前端展示效果,如下:

图2a-6
注:接下来正式打断点。
20250131周五时间段:23:31-23:40
20250131周五时间段:23:56-00:00
卡顿的conversationId是9256f52eda2c11efa0690242ac120006,放到测试用例里,如下:
def test_multi_chat(client):
log.info("test_multi_chat")
'''
测试多轮对话-包括三轮对话场景
'''
json_data = {
"conversation_id": '9256f52eda2c11efa0690242ac120006',
"question": '我家狗拉肚子'
}
url = f"/v1/conversation/multi_chat"
resp = client.post(
url,
json=json_data,
headers={
"Content-type": "application/json",
"Authorization": "Bearer ragflow-UxOGYzZjUwYjMwOTExZWZiODc0MDI0Mm"
}
)
if not 200 <= resp.status_code < 300:
raise Exception(f"GET {url} status_code {resp.status_code}.")
# received_data = []
for chunk in resp.iter_encoded():
answer = chunk.decode('utf-8').strip()
log.info(f"\n\n answer: {answer} \n\n")
注:打断点如下:

图2a-7
注:有点搞不明白,为啥是chat,追踪一下。
20250201周六初四时间段:00:07-00:20
20250201周六初四时间段:00:23-00:40
看了一下,方法错了,应该是multi_chat方法,而不是completion_multi_chat,multi_chat如下:

图2a-8
注:要对这个方法打断点,打断点进行测试。
20250201周六初四时间段:00:29-00:40
20250201周六初四时间段:01:13-01:20
对方法multi_chat打断点如下:

图2a-9
注:接下来,运行一下,看看效果。效果如下:

图2a-10
注:conversation没发现,看下这个是哪里报的,怎么着解决一下,研究了一下,明白了,需要改host文件,定位到测试服务器,修改host文件如下:

图2a-11
注:文字版如下:
###online
##39.101.69.172 mysql minio redis ollama es01 neo4j
###test
116.204.8.110 mysql minio redis ollama es01 neo4j
注:这个打开文件夹,看下,如果确实保存成功了,就运行一下,看能不能跑到打的断点。
20250201周六初四时间段:01:17-01:20在获取会话的地方,打个断点,看能不能获取到,截图如下:

图2a-12
注:发现是可以的,说明那个host配置生效了,继续往下走,看能不能跑到【完成基础问询】的断点的地方。
先修改一个地方,简化下写法,修改如下:

图2a-13
注:这样更清晰,尤其是dispatch不再依赖intention赋值。
跑的时候发现,无端的跑完了,追踪一下。
20250201周六初四时间段:01:39-01:40
20250201周六初四时间段:01:44-02:00
找到出问题的点,如下:

图2a-14
注:到循环这一步,直接结束了,不走断点了,修改下代码,打个日志看看情况。修改代码如下:

图2a-15
注:再跑一下,看看原因。连接超时了,截图如下:

图2a-16
注:文字版如下:
self.gen.throw(value)\n File \"e:\\16python\\12\\ragflow1203\\local_ragflow\\.venv\\Lib\\site-packages\\httpx\\_transports\\default.py\", line 86, in map_httpcore_exceptions\n raise mapped_exc(message) from exc\nhttpx.ConnectTimeout: [WinError 10060] 由于连接方在一段时间后没有正确答复或连接的主机没有反应,连接尝试失败。\n", "reference": []}} 注:把host到正式系统,把聊天记录拿过去。修改如下:

图2a-17
注:id换到282ece24da0411ef980a0242ac120006上,并把聊天记录换一下。并且修改host文件如下:
###online
39.101.69.172 mysql minio redis ollama es01 neo4j
###test
#116.204.8.110 mysql minio redis ollama es01 neo4j
注:这样换了之后,再测试下效果。发现刚才改的数据库是chat_sev,需要改成ragflow数据库,截图如下:

图2a-18
注:此时的conversation_id是e1026e72d8d511efbf8cf020ff63f4c4,这个运行一下,看看效果,效果如下,发现测不出来,需要再问几个问题,才可以,所以,代码合并到线上,继续回答几个问题,再进行测试。
20250201周六初四时间段:02:32-02:40把代码上线,继续回答几个问题,再进行判断哪里的问题。
拍摄于2025年1月4日,19:26:23,带二宝出去玩,当时二宝两岁三个月。感觉人生处处有遗憾,就像井兄弟,天资聪颖,本可以更有作为,但由于长期奔跑或什么原因,腿现在稍微走走就疼,休息一两年了,没太大好转。但怎么说呢,少了交通成本,可能有更多的时间编程,祝福他吧。

图2b-1
《本文完》