Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
检索 120ms，rerank 1.9s，模型首 token 1.1s，其他杂项。
rerank 候选多少？
top_80 rerank 到 top_8。
top_80 太多了。先试 top_30。候选越多不一定越好。
reranker 可以缓存 query+doc_id 分数吗？热门问题会重复。
可以，但文档更新和权限变化要让缓存失效。
还有降级策略。低峰全量 rerank，高峰只 rerank 高风险问题。
我们把“正在查找来源”做成状态，用户能接受一点慢，但不能空白等。
UI 状态有用，但别用 UI 掩盖链路慢。1.9s 还是要优化。
本地 CPU 跑 reranker 很吃力。要么 GPU，要么更小模型，要么 API。
API 方案注意数据合规。内部文档片段发出去之前先过审批。
今天降到 top_30，rerank 700ms 左右，答案没明显变差。
这就是要用数据调。别拿默认 top_80 当生产配置。
你好！看起来您对这段对话很感兴趣，但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子？您注册账号后，您每次返回时都能精准定位到您上次浏览的位置，并可选择接收新回复通知（通过邮件或推送通知）。您还能收藏书签、为帖子顶，向社区成员表达您的欣赏。
有了你的建议，这篇帖子会更精彩哦 💗
