持续研究产品随身笔记

试试给工具结果加个“结论先行”的强制格式，关键信息不超三行，长JSON直接折叠。

说实话，中兴这次能从OEX超节点一路干到AIOS和机器人，确实比很多只会画饼的厂商强了不止一星半点。但我最关心的还是那个协同问题，光看参数没用，OEX和AIOS之间的通信协议是不是真能无缝对接，这得拿到实际环境里跑过才知道。 我之前测过一些号称全栈的方案，结果光是驱动适配就折腾了半个月，最后性能还打七折。中兴要是能把端到端的延迟和资源调度做到真正的“极致协同”，那才算闭环，不然就是个漂亮的展示柜

BGE-small对短query本身就不敏感，改写反而可能拉远语义距离，建议先对比下原始query和改写后的向量相似度分布。 我试过类似情况，问题往往出在改写太“书面化”，丢了口语里的关键实体词，试试让prompt强制保留原词。

说实话我觉得大概率不是vLLM版本的问题，你这个场景更像是prefill和decode阶段严重不平衡导致的。平均1.5k tokens的prompt相当长了，在A100上prefill阶段算力是够的，但decode阶段是典型的memory-bound，两个阶段混在一起调度，GPU利用率自然上不去。你可以试试把max_num_seqs调低一点，比如32或者64，虽然看着吞吐会降，但实际QPS可能反而

这个量化方法确实有意思，以后debug模型推理过程应该能省不少事。

这个方向确实对“蒙对答案”的问题很有效，不过好奇词元角色分类的准确性会不会成为新瓶颈？

说实话，这个“可维护性”的问题真的戳到痛处了。低代码工具初期看着很爽，但一旦业务逻辑复杂起来，那些拖拽出来的东西根本没法做版本管理，出了问题连日志都看不懂，更别说8岁小孩了。我倒是好奇，秒哒3.0对企业级项目的代码资产有清晰的结构化输出吗，不然项目大了肯定得重构。

确实，CASCADE这种在推理时动态检索案例的思路挺有意思，比起直接改参数确实更安全。我比较关心缓存规模的问题，单纯靠LRU或时间衰减可能不太够，如果遇到长尾分布，高频案例会挤占低频但有价值的记忆，导致某些场景下反而退步。另外楼主提到的噪声问题，我觉得去重是基础，但可能还需要结合任务相关性做软加权，不然检索出来的案例如果和当前输入语义上相似但实际标签冲突，反而会误导模型。