INSIGHT对 UGC 搜索的 RAG 化摘要或答案生成，可以把高频帖子中的事实、实体和可引用句子预抽取为 nugget，并在查询时按需拼装上下文。关键不是盲目扩大 top-k，而是保留 nugget 的局部语义与原文位置；同时要把离线抽取、缓存存储和内容更新成本纳入整体 SLA。

INSIGHT多轮搜索问答不应每轮从零检索：可以把会话中的 query 意图、已验证帖子和无效候选维护成可更新的证据状态。对社区场景，页面信念记忆适合记录帖子是否真正解决问题，情节记忆承接改写 query，探索策略则避免早期误召回把后续答案锁死。

INSIGHT生成式搜索的答案质量受首阶段候选上限制约，固定 top-L 既可能漏召回，也可能浪费预算。可以先定义必须保持不变的融合结果，再让每个 query 自适应拉取更多 sparse/dense 排名；线上应同时监控 nDCG、召回覆盖、P99 延迟和实际访问深度。

INSIGHT对包含价格、时间、作者和标签关系的 UGC 搜索，纯向量相似度也可能把需要共同解释的字段拆开。生成式检索 Agent 应优先执行实体展开、字段过滤、邻接上下文恢复等可审计操作，再让模型生成答案，并把每一步的证据来源暴露给评测与回滚系统。

INSIGHT生成式搜索的 query 改写、摘要压缩和推荐理由生成都存在‘改得越多越好’的错觉。可以把不同改写模板、检索工具和输出约束作为 arms，按用户反馈与内容新鲜度更新衰减估计；当某模板连续带来重复结果时，主动探索比继续堆叠同一 prompt 更安全。

INSIGHT生成式搜索的离线评测应同时覆盖召回命中、证据引用、答案事实性、query 解决率和交互成本，并保留失败轨迹。可借鉴美团的业务化评测思路，把离线 benchmark、人工抽检与线上 CTR/nDCG 串成同一指标树，避免生成答案看似流畅却无法解决用户问题。

INSIGHT生成式推荐或搜索模型的成本瓶颈常在 embedding、KV cache、通信和 kernel，而不只是参数量。规划 UGC 业务试点时，应把模型结构、序列长度、缓存布局和硬件利用率放在同一 profiling 表中，用每千次请求成本与 P99 延迟约束规模化，而不是只比较离线 nDCG。

INSIGHT对社区搜索而言，长上下文模型不等于应把全部历史直接塞进 prompt。更现实的用法是将其作为低频 query 的重写、证据整合或结果解释模型，并用路由器按 query 难度选择本地模型；上线前要验证 P99 延迟、显存占用和内容安全边界。