标准回答
一、三个维度
LLM 输出的可靠性要从结构、安全、事实三方面用模型之外的确定性手段来保障,而不能只靠提示词「请求模型自觉」。
二、结构校验
优先从源头约束:用函数调用 / JSON mode / 约束解码(按 grammar/Schema 强制采样)让输出天然合法;再叠加 JSON Schema、正则、类型校验做兜底解析。失败时把校验错误信息回灌给模型让它修复,并限定重试次数,避免死循环。
三、安全与合规校验
对输出做敏感/违规内容过滤、越界话题拦截、PII 检测与脱敏;可用规则、分类器或审核模型,命中则拦截、改写或返回降级回复,并记录审计日志。
面试里可以补一句:校验与约束 LLM 的输出结构 / 安全 / 事实 在大模型场景下通常要同时权衡效果、延迟、成本和安全边界。回答时最好带一个例子,比如上下文过长、幻觉、缓存命中或工具调用失败时,系统应该如何降级和观测。
四、事实校验
RAG 场景检查输出是否有检索依据、引用是否对应原文(接地检查);用自一致(多次采样取多数)或独立校验器判断是否编造,无据则拒绝或重生成(参考 结构化输出实践,框架层面可用 LangChain 的输出解析器)。
常见误区
⚠️ 常见踩坑
误区一:容易答偏的地方:别只在 prompt 里写「只输出 JSON」就当校验——模型可能加解释、截断或越界;必须有程序化解析 + 失败重试,且结构、安全、事实三类校验各有侧重,不能互相替代。
追问
追问 1:约束解码和「校验后重试」哪个更好?
约束解码从生成源头保证格式合法,省去重试、延迟稳定,但需后端支持且灵活性受限;校验+重试通用、易实现但有失败开销。实践常组合:能用约束解码就用,再叠加 Schema 校验兜底。
追问 2:如何防止重试陷入死循环?
设置最大重试次数,每次把具体校验错误回灌帮助模型修正;超过上限则返回降级/兜底结果或转人工,并记录失败样本用于改进提示词与 Schema 设计。
追问 3:安全过滤放在模型前还是后?
两侧都要:输入侧过滤越界请求、Prompt 注入与 PII;输出侧再过滤违规内容与 PII 泄露。仅靠单侧会被绕过,输入输出双向校验才完整。
🔗 相似问题
同一考点的不同问法,换着练更稳
没找到想看的面试题?把你想看的告诉我们 →
延伸学习
按主题分类的相关资源,便于系统复习
