解决langchain-ChatGLM项目中知识库对话message_id缺失问题

问题背景

在langchain-ChatGLM项目的实际应用中，开发者发现知识库对话和大模型对话接口返回的数据中缺少message_id字段。这一缺失影响了评分功能的实现，因为评分接口需要依赖message_id来关联具体的对话消息。

技术分析

经过深入分析，我们发现问题的根源在于项目的数据流处理机制。在标准对话流程中，系统需要为每条消息分配唯一的标识符(message_id)，以便后续的追踪、评分和分析。然而当前实现中，这一关键字段在某些接口中未能正确生成和返回。

解决方案

针对这一问题，我们提供了两种解决方案：

1. 使用chat/completions接口的自定义参数： 开发者可以通过在请求体中添加conversation_id参数来实现message_id的生成和返回。具体实现方式是在请求的JSON体中添加一个32位的conversation_id字段。系统会识别这个参数并自动生成对应的message_id，同时将对话记录存入数据库。

   示例请求体：

   {
       "messages": [{
           "content": "问题内容",
           "role": "user"
       }],
       "model": "qwen1.5-chat",
       "stream": true,
       "tool_choice": "search_local_knowledgebase",
       "tool_input": {
           "database": "",
           "query": "查询内容"
       },
       "conversation_id": "12345678912345678912345678912345"
   }
   

2. 修改kb_chat接口的底层代码： 对于需要直接使用kb_chat接口的场景，开发者可以参考项目中的add_message_to_db函数实现，对接口进行改造，确保message_id的正确生成和返回。这种方式需要对项目代码有更深入的理解，适合有定制化需求的场景。

实现原理

在技术实现层面，系统通过以下关键代码处理conversation_id参数：

extra = {**body.model_extra} or {}
conversation_id = extra.get("conversation_id")

这段代码从请求的额外参数中提取conversation_id，进而触发message_id的生成机制。

应用建议

对于大多数应用场景，我们推荐使用第一种方案，即通过chat/completions接口的自定义参数来实现功能。这种方式具有以下优势：

1. 无需修改项目源代码
2. 实现简单，只需在请求中添加参数
3. 兼容性好，不影响现有功能
4. 便于维护和升级

对于有特殊需求的开发者，可以考虑第二种方案，但需要注意后续项目升级时的代码兼容性问题。

总结

通过本文介绍的方法，开发者可以轻松解决langchain-ChatGLM项目中message_id缺失的问题，为后续实现消息评分、对话追踪等功能奠定基础。这一解决方案不仅适用于当前版本，其设计思路也可为类似项目的开发提供参考。