RAG 界面的延迟，先从状态和请求边界查起

RAG 界面的延迟先从状态和请求边界查起带问答功能的知识库页面常有两股高频变化用户在左侧输入和筛选右侧持续接收流式回答。把它们都放在页面顶层状态里界面很容易越用越卡。问题不在于用了 RAG而在于每一小段流式文本、每一次键盘输入都牵动了不需要更新的区域。性能优化前先明确两件事什么状态只服务于当前回答什么状态才是多个区域真正共享的检索请求究竟由哪一个交互触发。边界清楚后许多不必要的渲染和请求自然会消失。别让流式文本拖着整页一起刷新流式回答通常只需要显示在答案区域。若它被放在页面根组件的 context 中每追加一段文本订阅这个 context 的列表、筛选器和导航区都可能重新执行渲染。即使某些组件加了 memo变化的对象引用和内联回调也可能让优化失效。比较稳妥的分法是把会话状态和答案展示状态分开。当前会话 ID、用户选中的资料、权限信息可以放在共享层频繁变化的回答文本留在 AnswerPanel 附近或由只被答案组件订阅的 store 保存。这样流式更新影响的范围很小列表滚动也不会被无关文字打断。不要把“所有状态上提”当成默认原则。状态离使用位置越远观察它的组件通常越多。真正需要跨区同步时再共享只为方便传参而扩大全局订阅范围后面会付出渲染成本。列表本身也要看数据规模。几百上千项资料同时挂在 DOM 上哪怕单项渲染很轻也会让输入和滚动变得吃力。虚拟列表适合处理长列表但前提是行高和焦点行为已经设计好。它不能替代状态隔离只是减少同时存在的节点数。检索请求不应该跟着每一次按键出发输入框的每个字符都请求一次检索通常只会制造相似查询和无用的中间结果。给输入加一个合适的等待时间并在新请求开始时取消仍在飞行中的旧请求能显著减少竞争。等待多久取决于产品节奏即时建议、完整搜索和显式点击搜索的要求并不相同不要套用固定值。还需要判断“值是否真的变了”。用户切换焦点、输入空格后又删掉或组件重渲染导致回调重新创建都不该启动一次新的向量检索。将规范化后的查询作为键记录最近完成和正在执行的请求可以避免同一内容重复进入后端。缓存也要谨慎。资料权限、索引版本、过滤条件和语言都可能影响结果只用原始文本做缓存键会把错误结果带给用户。缓存命中时应保留来源信息并让结果在索引更新后自然失效。对需要强一致的后台数据宁可少缓存也不能让用户看到不该看的内容。用采样而不是感觉判断改动是否有效浏览器性能面板和 React Profiler 能帮助定位更新来自哪里但一次录屏不能说明改动已经解决问题。应在相同数据量、网络条件和设备下对比输入、切换资料、接收长回答等关键路径。记录的内容可以很朴素一次搜索触发了几次请求列表组件提交了多少次交互到首个可见结果花了多久。流式 UI 还要关注更新频率。如果后端很快吐出细小片段前端每个片段都 setState浏览器可能忙于绘制而无暇响应滚动。可以在短时间窗口内合并显示更新或用调度策略降低非关键文本的优先级。目标不是让文本“晚一点出现”而是在阅读体验和输入响应之间做明确取舍。测试要覆盖取消请求和乱序返回。用户输入新词后旧请求可能晚到若不检查请求序号或 AbortSignal旧结果会覆盖新结果。这个问题看起来像检索质量下降实际是客户端没有处理并发顺序。一次修改只验证一条假设优化时很容易同时加 memo、虚拟列表、防抖、缓存和状态库最后不知道哪个动作有效也难以回滚。更好的顺序是先用 profiler 确认范围过大的更新再隔离流式状态确认请求过密后再处理防抖和取消列表确实成为瓶颈时才引入虚拟化。每一步都保留可观察指标和失败路径。比如模型回答断流时答案区应能结束 loading检索被取消时不应显示红色错误缓存不可用时页面仍可走正常请求。RAG 界面的性能并没有神秘捷径关键是让每种变化只影响它该影响的组件和请求。