[Feature]针对流式输出打开的情况下对不支持流式输出的平台的分割字符自定义的建议

[Haoxiang-Fant]

Description / 描述

在选项：不支持流式回复的平台（选择在不支持流式回复的平台上的处理方式。实时分段回复会在系统接收流式响应检测到诸如标点符号等分段点时,立即发送当前已接收的内容）中选择实时分段回复后会因为无法自定义分段符号可能导致分段过于频繁，引发机器人刷屏，希望可以增加分段符号自定义功能
流式输出的API响应较快，可以提升聊天体验所以有开启的必要

Use Case / 使用场景

聊天场景

Willing to Submit PR? / 是否愿意提交PR？

• Yes, I am willing to submit a PR. / 是的，我愿意提交 PR。

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct. /

[Dt8333]

#3547 (comment)
在这个PR曾讨论过关于适配器自带的分段输出相关问题。
回旋镖打回来了

另外，少数适配器中并没有实现分段输出。

我想有必要讨论一下：
适配器端的分段是否继续保留？（看起来是需要的。流式输出时分段能提供更快的首字响应？）
不支持流式输出的适配器的分段是否应当统一接入？（甚至将send_streaming统一接入避免忘写？（#7749））
适配器自带的分段输出的分段点是否应当和分段回复-分段正则表达式中保持一致，或者提供自定义配置的地方？

[Haoxiang-Fant]

您好：
先说一下，我基本不会编程😂
首先，如果开启流式输出的话，API返回结果的时间会大度缩短，因为我们只用等到LLM输出第一个字符就可以了，等LLM输出到到第一个分段符号的位置机器人就可以发送消息了，不需要等LLM将全部内容生成完才能进行下一步操作（这么一来LLM调用成功率估计也有一定的改善，因为只用等一个首字时间就有API的响应，避免Astrbot判定超时。您应该知道，原谅我多嘴

回答：适配器端的分段是否继续保留？

根据这个问题，我能够理解的是现在Astrbot的分段器不是统一的？会根据不同的适配器进行定制？
那我有一个非常大胆的想法，顺便回答问题二。
根据我的理解，Astrbot有两种分段器，分别针对非流场景和流式场景。在非流场景下，Astrbot是在LLM返回的内容里面将需要发送的文本提取出来，调用适配器（比如NapCat，如果我对适配器的理解没错的话）将信息发送出去，而分段就是先将文本发送给分段器，分段器分段完成后再按照相关的延时设置发送给适配器。而在流式场景下，Astrbot可能是采用了类似监听？（我不知道怎么形容）的手段进行分段，即看到分段符号就立刻将在缓存的内容发送给适配器。
所以我们可不可以把非流场景的文本用流式的方法发送给流式的分段器呢？Astrbot收到LLM输出的内容后，在本地把要进行分段的文本用流式输出给流式输出的分段器？这样用户只用设置一次分段符号就可以在非流和流式输出这两种模式体验到相同的效果了

回答：适配器自带的分段输出的分段点是否应当和分段回复-分段正则表达式中保持一致，或者提供自定义配置的地方？

这个我认为是有必要保持一致的，如果用户特地设置了分段正则表达式，说明有这个分段需求，若不一致的话可能需要重新配置，会比较麻烦

由于我唯一的编程经历是高中的Python基础课程，所以如果出现了什么很好笑的错误，请不要笑话我QWQ
感谢愿意花费时间看完我的想法

[Dt8333]

由于我唯一的编程经历是高中的Python基础课程，所以如果出现了什么很好笑的错误，请不要笑话我QWQ 感谢愿意花费时间看完我的想法

？为什么要笑话啊。个人认为，哪怕真的有理解上的错误，至少这也是用户反馈。用户在尝试自己理解并解决问题，我觉得应当鼓励。这能一定程度更加了解问题和需求，也有利于减少解决问题所需的工作量。

首先，如果开启流式输出的话，API返回结果的时间会大度缩短，因为我们只用等到LLM输出第一个字符就可以了，等LLM输出到到第一个分段符号的位置机器人就可以发送消息了，不需要等LLM将全部内容生成完才能进行下一步操作（这么一来LLM调用成功率估计也有一定的改善，因为只用等一个首字时间就有API的响应，避免Astrbot判定超时。您应该知道，原谅我多嘴

理解了。这个是的确应当保留的。

根据这个问题，我能够理解的是现在Astrbot的分段器不是统一的？会根据不同的适配器进行定制？

这应当算是目前实现上的问题。目前适配器的分段器都写在send_streaming函数内。这个函数用于接受流式生成的消息并进行处理，发送。
由于流式输出时，中间过程并不能获知完整内容。接受完整内容并进行分段的处理器（非流式输出分段）并不能对流式内容进行分段。
而有的适配器并不能支持真正的流式输出（对已发出的消息进行延长，修改，实现逐字显示的效果），只能等待一条消息结束后发送。分段发送可以以最快速度拆分已收到的部分文字并发送，而不必等消息完全结束。

在非流场景下，Astrbot是在LLM返回的内容里面将需要发送的文本提取出来，调用适配器（比如NapCat，如果我对适配器的理解没错的话）将信息发送出去，而分段就是先将文本发送给分段器，分段器分段完成后再按照相关的延时设置发送给适配器。

基本正确。

而在流式场景下，Astrbot可能是采用了类似监听？（我不知道怎么形容）的手段进行分段，即看到分段符号就立刻将在缓存的内容发送给适配器。

基本正确。适配器端将已收到的文本存入缓存区，并循环检查。将符合条件的部分取出并发送。

所以我们可不可以把非流场景的文本用流式的方法发送给流式的分段器呢？Astrbot收到LLM输出的内容后，在本地把要进行分段的文本用流式输出给流式输出的分段器？这样用户只用设置一次分段符号就可以在非流和流式输出这两种模式体验到相同的效果了

这个恐怕只会取两方之短。非流式下收到完整信息才会开始进行下一步处理。将它当成流式处理，后续的信息修饰等插件钩子是不可用的。结果会是在更长的响应时间获得更少的功能。

回答：适配器自带的分段输出的分段点是否应当和分段回复-分段正则表达式中保持一致，或者提供自定义配置的地方？

这个我认为是有必要保持一致的，如果用户特地设置了分段正则表达式，说明有这个分段需求，若不一致的话可能需要重新配置，会比较麻烦

了解。也许将适配器的正则改为读取配置文件，而不是只使用预设会比较好。
需要研究一下是否需要对新的正则添加新的要求。

另：在适配器分段中将正则写死也许有性能上的考量。
这样在消息碎片中送入特定符号时才会触发正则匹配，而不是每个消息碎片都进行一次匹配。
允许用户自定义这里的正则可能需要考虑这个性能问题如何解决。