INSIGHT对社区短文本搜索，先按召回器类型决定是否启用 LLM 重排：BM25 候选更值得尝试，对强 dense 候选应先做增量收益评估。上线前必须记录 tokenizer、截断、anchor 拼接等实现细节，并用 query 分桶验证收益，避免把论文中的复杂结构直接照搬到 P99 链路。

INSIGHT社区搜索的低置信 query 可进入更贵的重排或人工兜底，但 raw relevance score 不能直接当路由概率。建议在现有校准层后增加 label-wise reliability 特征，分别评估 nDCG、ECE、fallback 命中和延迟；这样能把‘结果相关’与‘系统是否该相信它’拆开优化。

INSIGHT搜索系统的语义缓存、去重和 query 改写门禁不能只看 cosine。应增加反转、否定、数值和实体替换样本，采用 matched-pair 离线审计，并把阈值按 query 类型校准；论文中少数配置在配对审计上达到 AUROC 0.79–0.90，说明评测设计比盲换 encoder 更关键。

INSIGHT社区搜索的长尾短句常把多个意图压在一个 query 中，直接 embedding 容易丢掉实体关系。可先只对高复杂度 query 启用轻量分解，分别生成词法扩展和语义解释，再用 RRF 或学习融合合并候选；同时监控 query 膨胀、重复召回和额外延迟，避免所有请求都走 LLM。

INSIGHTUGC 搜索离线评测中，LLM judge 的角色设定可能改变长尾 query 的标注门槛。建议固定一套标准 persona，同时用至少两种任务 persona 做压力测试，报告系统排序一致性和 query 级 rank displacement；发现敏感桶后再回看标注定义，而不是只追逐一个总 nDCG。

INSIGHT社区短文本的 hard negative 应先做来源审计，再用于训练。可把词汇残差、语义邻近和正例一致性作为数据质量特征，按来源预估迁移性；对疑似 false negative 保留 audit profile，不要简单加权采样，否则会把‘看起来难’的错误负例灌入 retriever。

INSIGHT社区帖子、话题、作者和实体关系可组成轻量 corpus graph，适合在 dense 召回漏掉关键上下文时做受控扩展。工程上应把语义扩展、图剪枝和时延预算分开埋点，用 Topological Recall 类指标检查是否找到‘中间线索指向的未召回节点’，避免无界图遍历拖垮在线链路。

INSIGHT社区内容逐步包含图片、截图和图文混排，纯文本 dense retriever 会漏掉视觉证据。可借鉴其非对称 encoder 与 teacher-space 蒸馏，把文档侧视觉容量和 query 侧轻量编码拆开；上线前需同时测索引体积、更新速度、图文 nDCG 与纯文本回退质量。

INSIGHT对社区 UGC，实体、话题和属性抽取可以作为 query expansion 的结构化中间层，但不宜直接让 LLM 自由生成扩展词。建议先把实体层级、来源和置信度落库，再与 BM25/dense 结果做可解释融合，并用长尾 query 的召回覆盖和误扩展率做门禁。