INSIGHT搜索排序不必把所有判断都压在请求时的 query-document 交互中；内容质量、文档效用、作者可信度等查询无关信号可先形成可审计先验，再与语义相关性融合。对 UGC 搜索，这能在几乎不增加在线计算的情况下补偿纯相关性模型的偏差，并为后续个性化先验留下接口。

INSIGHT多条件 query 的主要瓶颈不是召回率，而是排序分数允许某个强匹配条件掩盖其他条件缺失。社区搜索遇到“地点＋品类＋属性”组合需求时，应显式维护逐条件覆盖状态，以最弱条件或乘积聚合，并把部分满足样本作为硬负例；单纯扩大 embedding 模型或追加通用 reranker 并不可靠。

INSIGHT生产检索的可靠性来自可测的多路召回和专用相关性模型，而不是让生成模型包办排序。对企业或社区知识搜索，可先用 query 类型决定稀疏、稠密、图通道权重，再对低置信结果触发纠错；论文也提醒，图通道与 agent 循环的边际收益有限，应先把 cross-encoder 和评测集做扎实。

INSIGHT垂直搜索的增益来自“专用语料结构＋开放网页覆盖＋统一重排”，而不只是更换 embedding。社区 UGC 搜索也可把正文、作者、话题、互动关系分别建模，再与全站索引融合；同时应增加“已知目标”和“模糊回忆”两类评测，避免只用关键词明确的查询高估线上体验。

INSIGHTquery 改写不是默认正收益：口语化、省略严重的社区对话可受益，但包含金额、日期、型号等精确约束的查询容易被改写漂移。可落地做法是先用规则或分类器判断是否需要改写，保留实体与数值约束，并把原 query 与改写 query 并行召回；reranker 则是更稳定的第一优先级。

INSIGHT低资源搜索不一定先做领域微调，可把首轮召回当作伪反馈池，用 LLM 产生分级相关性，再以小权重更新 query embedding。实践中应优先试混合提示与 α≈0.1–0.5 的受控融合，并离线缓存或使用小模型；同时要防止错误伪相关文档把查询方向持续拉偏。

INSIGHT当有效证据只占页面很小区域时，整页送入 VLM 会同时浪费 token 并稀释语义；正确顺序是先用低成本全局锚点确定意图，再裁剪局部高价值区域精读。该设计可迁移到含截图、长图、商品参数表的 UGC 搜索，但需要可靠版面解析和离线构图管线。

INSIGHT词法、不同稠密编码器和 cross-encoder 的误差具有互补性，简单 RRF 往往比强行统一分数空间更稳。社区搜索可保留 BM25 保障实体词和新词召回，再让两类 embedding 扩大语义覆盖，最后把有限候选交给重排；上线前应按 query 类型监控各通道增益与延迟。

INSIGHT精简、可控的单次改写优于盲目生成更多 query，且技术类语料适合确定性解码，开放域才需要少量随机性。可在社区搜索按领域设改写温度，并跳过已独立完整的首轮 query；论文实测跳过首轮改写保持 nDCG 不变，同时将该阶段耗时降低 29%。