feat(chat): Fold the output of the reference content of the search mo… #83
Conversation
…del AND remove reference content from prompt
|
我的建议是联网的参考检索，也放进思考reasoning_content里，各个客户端现在也都对官方api做了兼容，肯定没啥问题 |
+1 感觉放在 reasoning_content里更合适 |
我不赞同把字段定义混淆的行为，这种行为可以明确是屎山代码的开始 并且那只是看上去会比较方便，使用起来并不理想，比如客户端或不支持思考内容 markdown 渲染导致页面过长，使用非思维链模型时出现思考内容从而造成困扰等等 既然 |
我们没法定义新的字段，因为不会有客户端支持，静默模式下放在reasoning_content里是最好的选择，普通模型可以全部输出来，但是静默模式，放在reasoning_content我认为是一种更好的选择， |
看上去静默不输出是现有功能，仔细阅读README，不过我暂时并没有使用静默模式的需求，不考虑对它进行修改，It's not my busniess at now
我使用的所有客户端都支持markdown，markdown语法也已经成为输出格式共识，包括众多模型官方web或app，或许你应该去提 feature request 给那些你了解的客户端 |
放到content里面在多次会话时会污染上下文，目前退而求其次放到reasoning_content里可能是当下最优的选择了 |
😩 或许你应该先 review 一下代码，就几行而已，又或许你至少要看一下 pull request 的描述。 |
抱歉是我表达的不清楚，在使用api的时候，多轮聊天过程中有时候会开个分支会话，然后使用其它模型回答进行比较，其它模型回答的时候是不会去掉检索内容的，所以在使用其它模型进行对比回答时会污染上下文，并且浪费token |
的确是会这样，其实我处理那个的原因也只是因为它会报错，因为我看了一下我另一个支持插件的客户端，它在使用插件进行 web search 后也会把搜索结果放到上下文里。 它用的是 Function Calling，会有一条 role 为 tool 的信息，客户端在多轮对话时不会删掉这个条消息，所以觉得这应该是一般api接入时使用搜索的普遍用法？ 所以如果要给 参考检索 一个特定位置的话，应该回朝这个方向去做，但它稍微麻烦一些，并且看上去区别不大。 
|
个人看法：无论用的什么插件，最后混在上下文里的如果只有网页标题和链接而没有实质内容的话，它带来的干扰要比它所含的信息要大的多 |
当前这个项目是一个 api 仿造项目，设计时是不关注 是否放入上下文 的，因为对于 api 来说，它是无状态的，都是单次独立请求甚至没有上下文的概念。这应该是客户端关注的内容，客户端可以提供操作以实现它。比如在我这款客户端中，如果我不希望它进入之后对话的上下文，那我可以把这条消息删掉。 当前项目应该只关注是否符合现有 api 标准，虽然当前实现会有一些不符合 Function Calling 的格式，但因为实现起来会更麻烦但使用上差别不大，所以目前不太有动力去做这个事情。并且一般现代客户端会提供 消息编辑 的功能，可以通过这个功能把它排除出后续对话的上下文。 
|
#64
使用 markdown 标签折叠联网的 参考检索，并且在多轮发送消息是将先去的 参考检索 去除掉，否则无法正常使用，会返回“还没学会”