问题: 当 LLM 流开始时进行恢复,但从未到达句子结束(慢流窗口)

问题: 当 LLM 流开始但停滞(多秒钟没有句子结束)时,有哪些记录在案的恢复方法? ** 设置: pipecat 1.10.0(现为 1.11.0),OpenAIResponsesLLMService(GPT-5.6-terra,流式传输),Deepgram Flux STT,Telnyx 传输,基于句子的 TTS 聚合,retry_on_timeout=True/retry_timeout_secs=5在 LLM 上。 ** 发生了什么(真实呼叫,2026 年 9 月 16 日 08:23-08:25Z): 首个 token 正常到达( metrics.ttfb 平均 1.37 秒,最大 2.93 秒,共 9 次请求),但从某个点开始,流从未到达句子结束:部分文本(例如"抱歉,你是否指的是哪个游泳")在没有句子边界的情况下停留了 3.7/5.5/3.5/8.9 秒,因此没有任何内容传输到 TTS,机器人保持沉默。 来电者说"你好?"三次;每次"你好?"都是中断,导致在飞行中取消回复( ABORTED_TURN 在任何句子播放之前),下一个回复开始并以同样的方式取消,来电者在保持沉默约 22 秒后挂断。同一 40 分钟窗口内的两个其他呼叫在不同机器上都出现了 LLM TTFB 最大值为 20-22 秒,因此这似乎是提供商缓慢流式传输窗口,而不是管道端的任何问题。 PipelineWorker 心跳警告("未在 10.0 秒内收到心跳帧")在整个过程中发出。 ** 在 docs/source 中我找到的内容:** retry_on_timeout 适用于在 retry_timeout_secs 内未生成任何输出的请求(静默开始)。我无法在文档中找到关于已启动但速度太慢无法到达句子结束的流的记录在案的设置,也无法找到记录在案的 LLM 备用服务,也无法找到记录在案的方式来在第一个句子迟到时说出保持线路。 ** 问题: 1. 是否存在记录在案的设置,可以限制第一个句子的时间(或 token 之间的时间),并重试或取消流,就像 retry_on_timeout 可以限制第一个 token 的时间吗? 2. 是否存在记录在案的模式,用于备用 LLM(或口头保持线路),当流停滞时,还是这种行为有意地留给应用程序代码吗? 3. 上述行为(每次来电中断都取消了一个缓慢回复,因此一个缓慢窗口累积成完全沉默)是预期的交互,是否存在建议的配置? 由于触发是由提供商端的缓慢窗口引起的,我无法按需重现;很高兴在您能够提出模拟缓慢流的方法时运行一次。