重述用户消息

• 查询重写
• 上下文重写
• 根据历史对话，把用户当前提问不完整、依赖上下文的问题，改写成一个能被大模型理解的完整问题。
• 保证多轮对话的上下文完整性

主要作用

解决多轮对话中的：

• “它”“这个”等代词指代
• “第二种方案”等上下文依赖
• 省略了主体、参数或条件的问题
• 用户表达过于简短导致检索不准确的问题

简单来说：重述用户消息，是把多轮对话中依赖上下文的简短问题，补全成一个语义完整、可以独立理解的问题

rewrite_query

• 流程 rewrite_query → retrieve → grade_context

text

用户原始问题
  → rewrite_query：生成适合检索的独立查询
  → retrieve：从知识库召回相关资料
  → grade_context：判断资料是否足以回答

遵守三个限制：

• 最多重写、重检索 1～2 次。
• 始终保留原始问题，生成回答时使用原始问题。
• grade_context 失败后允许明确回答“资料不足”，不要为了走完流程强行生成。

如何判断需要rewrite_query重写查询？

• 当前问题单独拿出来做 embedding，是否还包含足够的检索语义。
• 存在指代
  • 比如它、这个、那个、这里等等
    • 需要补充历史上下文
• 存在省略检索对象
  • 多久？ 如何申请？ 支持吗？
    • 需要补充历史上下文
• 包含依赖历史的比较关系

方案

• 1、每个问题都交给模型分析，让大模型来判断用户的语义问题
  • 缺点是每次请求多一次模型调用，会增加延迟和费用
  • 企业级做法：LLM 做语义解析，代码做约束
    • 让大模型在一个有限范围内的语义判断 （充当大模型分析员）
    • 代码做约束，传给大模型当前对话历史、不要把失败消息、敏感配传给模型、模型返回结果的结构检验
• 2、自己写检查规则。【不推荐】
  • 太多规则、难以维护
  • 很容易误判
  • 规则会不断膨胀
  • 无法真正理解上下文