INSIGHT生成式召回不应只生成一个黑盒 item ID，关系类型可以成为可解释的检索控制面。对社区搜索，可把帖子、作者、主题之间的关系蒸馏为带 facet 的候选生成，并用约束解码保证 ID 有效，再用关系权重过滤无依据结果。

INSIGHT社区短文本的内容粒度差异很大，统一长度 token 容易在短帖子上浪费容量。可先离线统计 token 共现和行为转移，采用变长历史编码、定长目标解码的折中，重点观察序列长度、长尾 item 和 beam 解码延迟的变化。

INSIGHT扩散式生成推荐不能只编码内容语义，还要把“哪些 item 经常共同出现”作为结构先验。工程上可从共现图提供噪声或采样权重，但需要单独监控热门 item 放大、冷启动 item 覆盖和多步去噪带来的线上延迟。

INSIGHT“解释更好”不等于“推荐更准”。对 UGC 搜索/推荐，应把推理轨迹质量与 nDCG、CTR、长尾覆盖分开评估，先做无推理生成基线，再用奖励函数把可解释性成本与最终点击或相关性目标对齐。

INSIGHT生成式搜索和推荐的内容池需要记录来源与生成链路，不能把模型生成文本当作普通 UGC 继续回灌。应建立 AI 生成内容标记、采样隔离和分布漂移监控，并在离线评估中比较原生内容与递归污染内容的覆盖和多样性。

INSIGHT对复杂 query，不要默认把更多帖子塞进一个 context。可将召回、证据验证、答案生成拆成可观测轮次，用 leave-one-out 估计每批候选的真实贡献，再依据增量 recall 与延迟动态分配预算。

INSIGHT生成式推荐的线上瓶颈不只在模型精度，也在长上下文、KV 状态和权重恢复。部署时应把恢复路径纳入 SLO，分别测量权重加载、kernel 初始化、KV 状态恢复与首 token 延迟，并为低峰弹性缩容保留可快速唤醒的影子实例。

INSIGHT生成式推荐系统可借鉴“模型—服务—硬件”共同设计，而不是只替换 Transformer。评估时应把每次成功推荐的 token、延迟、能耗和重试成本纳入统一账本，用 useful intelligence per dollar 约束模型规模扩张。

INSIGHT生成式搜推服务中的工具调用、重排和内容后处理也会形成串行关键路径与突发并发。容量规划应看完整 session 的完成数，而不是只看核数或峰值吞吐；对线上链路要单独测量串行 tail latency、fan-out 并发和内存利用率。