1. LLM-as-a-Judge 怎么设计核心思路把Judge当成一个打分模型固定输入结构、明确评分维度、定义打分规则、增加校验防幻觉不要让大模型自由发挥。整体结构输入模板4部分任务描述告诉Judge它是什么角色、要干什么参考标准答案Golden Answer可选用户原始query被测模型输出评分维度RAG场景示例事实正确性答案是否和知识库一致有无编造信息信息充分性是否完整回答用户问题有没有缺关键信息忠实度Grounding所有结论是否都能溯源到检索片段有无幻觉有用性回答可读性、是否贴合用户意图评分规则设计推荐1~5分制每一档写死判定标准避免模糊描述5分完全正确信息完整全部内容可在参考文档找到无额外编造4分基本正确少量无关信息不影响结论无事实错误3分部分正确关键信息缺失无严重幻觉2分存在事实错误回答偏离问题1分完全错误/拒绝回答/大量幻觉输出约束强制要求Judge先输出【思考过程】再输出【分数】最后输出【理由】增加自校验让Judge自查是否存在信息和参考文档冲突。一致性提升手段少量样本人工校准Few-shot放入2~5条人工标注好样例重复打分同一条样本跑2次计算打分一致性差异过大标记人工复核增加反事实样本测试Judge本身能力可直接复制Prompt模板你是RAG评测专家需要对大模型回答进行打分。 评分维度事实正确性、信息充分性、内容忠实度不能编造知识库不存在信息。 打分范围1~5分。 评分标准 5分答案完全符合参考文档信息完整无编造准确回答问题 4分答案基本正确少量无关内容无事实错误 3分部分信息正确关键信息缺失不存在严重幻觉 2分存在事实错误回答偏离用户问题 1分答案完全错误大量编造信息。 【用户问题】 {user_query} 【检索参考文档】 {retrieved_context} 【被测模型输出】 {model_response} 输出格式严格遵守 思考过程 总分 理由2. 大模型评测数据怎么处理分为数据集构建 → 清洗 → 标注 → 版本管理 → 结果分析数据集来源人工编写覆盖正常、边界、歧义、对抗、幻觉诱导case线上真实query抽样脱敏过滤隐私数据历史bad case线上幻觉、回答错误、召回失败样本数据清洗脱敏手机号、身份证、内部敏感信息剔除去重相同query合并过滤无效样本空白、乱码、无意义问题标注构建Golden set人工写标准答案标注预期行为分层简单集、困难集、对抗集版本管理评测集像代码一样Git管理每次模型迭代固定版本数据集记录样本标签类别、难度、预期错误类型结果处理统计各维度指标按样本分组看通过率错误归类幻觉、召回错误、理解偏差、指令遵循失败Bad case回流加入下一轮评测集3. LLM测试和传统服务端测试有什么区别维度传统服务端接口测试LLM/大模型测试输出特性确定性相同输入固定输出概率性相同输入多次结果不一样校验方式精确匹配返回字段、值断言明确很难精确匹配多用LLM-as-judge、人工评估、事实校验缺陷类型报错、参数异常、数据库错误、超时幻觉、逻辑错误、答非所问、事实错误不一定抛异常用例设计输入输出明确结果可预期大量边界、歧义、对抗、诱导类用例性能指标响应时间、QPS、错误率吞吐量生成速度、召回质量、幻觉率版本迭代接口契约稳定模型权重、Prompt变更都会改变输出契约不稳定一句话总结传统测功能是否按代码逻辑执行LLM测输出内容质量、事实可靠性、意图理解能力。4. RAG测试集怎么设计和迭代设计思路分4大类样本正向标准样本问题答案明确存在知识库测试正常召回回答信息缺失样本知识库没有答案预期模型应该说不知道不能编造重点测幻觉模糊/歧义样本问题描述不清测试模型是否合理追问或者区分意图干扰样本知识库存在相似但是冲突的文档测试会不会被干扰召回错误片段测试集字段建议query、golden_answer、expected_behavior、reference_docs、difficulty、label迭代流程初始版本人工编写覆盖业务核心场景模型跑评测集收集bad case幻觉、召回错误把失败样本清洗后加入评测集扩充困难集定期引入线上真实query持续补充定期清理过时文档对应的样本知识库更新后同步更新测试集保持测试集固定子集作为基准集每次版本对比保证指标可横向对比5. Agent怎么找到正确的SkillSkill 工具查询数据库、发邮件、调用接口等Agent选择Skill完整链路用户输入 → Agent意图识别解析用户需求判断需要什么能力Skill描述库检索每个Skill有自然语言描述功能、入参、适用场景、限制匹配LLM根据用户问题对比Skill描述选出候选Skill列表校验判断参数是否齐全缺少参数就向用户询问执行选中Skill拿到返回结果整理回答关键点Skill描述写得好不好直接影响选择准确率描述要清晰、区分度高避免多个Skill描述相似混淆。6. Agent 和 Skill 的匹配机制怎么验证分三层验证单元级、链路级、评测集评测① 单元测试Skill选择能力构造评测query集合覆盖需要调用A工具需要调用B工具不需要调用任何工具直接大模型回答多个工具可选只能选其中一个需要连续调用多个Skill多步工具调用统计指标工具选择准确率、参数提取准确率② 边界对抗case用户问题模糊缺少入参验证Agent是否会询问缺失参数用户需求超出所有Skill能力验证Agent不强行调用工具不编造结果用户诱导调用危险工具安全校验拦截③ 链路完整评测端到端评测从用户提问 → 选Skill → 参数生成 → 调用工具 → 结果整理指标Skill选择命中率参数生成正确率参数名称、格式、取值完整任务成功率最终结果是否满足用户目标错误类型归类选错工具、参数错、多调用/漏调用工具④ LLM-as-Judge辅助评估Judge判断Agent选择的工具是否是当前问题最合适的Skill参数是否合理。7. Agent 输出怎么评测Agent 不是只看最终一句话回答要分层评测意图→工具选择→参数→中间步骤→最终结果评测维度意图识别是否正确理解用户诉求Skill/工具选择选对工具、不瞎调用、不多调用、不漏调用参数生成参数名、类型、取值正确缺参数时主动询问用户多步规划能力复杂任务能否拆解成合理步骤顺序是否正确工具结果处理拿到工具返回后能否正确解析不编造工具返回之外信息最终答案质量事实正确性、完整性、忠实度LLM-as-Judge打分安全指标拒绝越权、危险调用防止指令注入评测方式黄金集Golden Set人工标注样本包含预期工具调用序列预期输出LLM-as-JudgeJudge判断工具调用序列是否合理、最终结果是否满足用户目标指标工具选择准确率、参数提取正确率、任务完成率、幻觉率、多余调用率Judge PromptAgent专用可直接复制你是Agent评测专家。评估Agent执行整个任务链路是否合理。 评分维度 1.意图理解是否理解用户问题 2.工具选择是否选择正确工具无多余/遗漏调用 3.参数正确性工具入参是否合理、完整 4.步骤规划多步骤任务顺序是否合理 5.最终结果是否解决用户问题无编造信息 打分1~5分 5完全匹配预期步骤合理结果正确 4微小瑕疵不影响任务完成 3部分正确关键信息有缺失 2工具选错/参数错误任务失败 1完全偏离需求大量幻觉 【用户Query】 {user_query} 【Agent Trace完整链路】 {agent_trace} 【预期Golden行为】 {golden_trace} 输出 思考过程 总分 理由8. 并行节点冲突怎么处理Agent workflow多分支并行并行冲突多个并行节点同时读写同一个State出现覆盖、脏数据、状态不一致。状态隔离优先方案并行分支使用独立子State并行节点只读写自己分支内数据并行全部完成后做一次合并到主State。避免并行写同一个key。加锁机制共享全局State增加读写锁同一时间只允许一个节点写读可以并发。缺点锁会削弱并行能力。冲突合并策略预先定义合并规则覆盖策略后执行结果覆盖前面慎用追加策略数组类数据追加不覆盖投票策略多个并行分支产出结论不一致时交给LLM做结果汇总裁决冲突检测并行全部结束时校验同key下多分支产出是否矛盾冲突标记告警人工或LLM仲裁。避免长事务并行节点尽量无状态业务逻辑放到Skill里执行State只存元数据减少并行写压力。9. Trace 怎么做Agent链路追踪Trace目标记录Agent完整执行链路用户输入 → 思考 → 工具选择 → 参数 → 工具返回 → 模型输出方便调试、评测、定位bad case。核心字段trace_id全局唯一、start_time、end_time、user_query、state快照、每一步step_id、节点类型LLM思考/Skill调用/判断分支、prompt、模型输入输出、工具名称、入参、工具返回、错误信息、token消耗。实现方式埋点每一次大模型调用、工具调用、状态变更自动记录日志持久化存入数据库 / LangSmith / Langfuse / OpenTelemetry支持按trace_id查询完整链路可视化展示流程图每一步耗时、输入输出、异常标红关联评测Trace直接喂给LLM-as-Judge做自动评估Bad case直接保存进评测集采样线上全量采样成本高可抽样记录失败case强制全量保存Trace10. Agent 结果不理想怎么定位排障思路按链路从前往后逐级排查用户Query层query歧义、模糊、信息不足 → 看意图识别是否出错Prompt/系统提示词层Agent指令描述不清、Skill描述模糊 → 导致选错工具State层上下文丢失、历史状态污染、并行状态冲突 → 看Trace里State快照Skill匹配层Skill描述相似度太高区分度不足参数schema定义缺陷 → 参数提取错误工具执行层Skill本身报错、接口返回异常、超时、返回数据格式混乱结果生成层大模型拿到工具返回后错误解读、编造信息幻觉排查手段拉取完整Trace逐step看输入输出隔离测试单独测意图模块、单独测Skill选择、单独测工具调用消融实验去掉某一个组件看结果变化定位根因归类bad case是意图问题 / 工具选择问题 / 参数问题 / 工具返回问题 / LLM幻觉11. Checkpointer、State、Skill、MCP 怎么理解StateAgent的内存保存整个会话上下文、用户信息、中间结果、工具返回数据。贯穿整个workflow所有节点读写State。Checkpointer 状态检查点负责把State持久化。Agent中断、超时、重启后可以从checkpoint恢复State继续执行任务。比如LangGraph的Checkpointer。作用断点续跑、会话持久化、重试、回溯历史状态。SkillAgent可调用的能力单元也就是工具。比如查数据库、调用接口、文件读取。每个Skill包含自然语言描述、入参JSON Schema、执行函数。Agent依靠描述理解什么时候调用这个Skill。MCPModel Context Protocol模型上下文协议标准化协议让大模型Agent和外部工具、数据源统一通信。作用统一工具描述、参数格式、返回结构不同Agent框架可以直接接入MCP的Skill不用重复写适配代码。类似Agent世界的REST协议。一句话串起来Agent读取State基于State判断调用哪个Skill执行过程中Checkpointer不断保存State快照Skill通过MCP协议标准化对外提供能力。12. 怎么用 Codex 做自动化测试CodexOpenAI代码生成模型擅长代码解析、生成单元测试、生成接口/自动化脚本。使用场景根据接口文档、函数代码自动生成单元测试用例pytest根据业务需求生成Playwright UI自动化、requests接口自动化脚本代码变更后自动识别改动函数增量生成测试代码分析代码自动找出边界case、异常分支生成mock代码落地流程输入上下文源码/接口定义 测试要求pytest、mock、覆盖异常分支Codex生成测试代码自动执行代码捕获执行报错把报错信息丢回给Codex自动修复脚本人工Review生成代码校验断言逻辑重点AI容易写出假断言可集成CI代码MR触发自动生成并执行测试局限面试必说Codex生成代码容易存在幻觉断言错误、mock逻辑不对、忽略业务隐藏规则必须人工评审不能直接上线复杂业务逻辑场景效果差。13. 你们是怎么实现LLM 可观测可测评的测开面试口述版整体思路链路埋点采集Trace → 指标看板做可观测 → 评测引擎做质量评估两者打通一条Trace直接进入评测流水线埋点采集基于OpenTelemetry / Langfuse SDK做埋点对RAG/Agent的每一步query改写、检索、重排、LLM生成、工具调用生成Span。采集内容输入prompt、模型输出、token消耗、耗时、错误、检索文档、版本信息、用户id、trace_id。可观测线上监控基础指标TPM、请求量、耗时P50/P90/P99、错误率、模型拒绝率、token消耗链路视图可视化Trace定位慢调用、异常步骤失败样本自动标记告警超时、高错误率、token突增、幻觉类BadCase告警可测评离线在线评测离线固定Golden评测集批量跑自动生成Trace调用LLM-as-Judge打分计算幻觉率、召回率、忠实度在线采样线上按比例采样Trace送入Judge自动评估人工标注入口标注结果回流更新评测集问题归类自动把失败样本分类检索错误、query改写错误、模型幻觉、重排错误闭环评测识别的BadCase直接入库加入下一轮回归评测集模型/知识库版本变更时自动跑全套评测质量门禁卡点。14. 如果从零设计 LLM 可观测平台核心模块技术选型核心模块SDK埋点采集模块提供多语言SDKPython/JS/Java兼容OpenTelemetry自动埋点LLM调用、RAG各阶段、Agent工具调用支持手动自定义Span。Trace接收存储模块接收Span事件做数据清洗、脱敏存储链路明细。指标计算模块实时聚合指标QPS、TPM、耗时分位数、错误率、模型拒绝率。可视化链路看板Trace详情页、DAG流程图、时序指标大盘按trace_id检索全链路。评测引擎模块评测集管理golden样本管理、版本管理LLM-as-Judge执行引擎支持自定义Prompt、批量评测指标报表NDCG、召回率、幻觉率、任务成功率标注样本管理模块人工标注界面线上采样样本入库BadCase管理样本回流告警与通知模块指标告警、质量指标告警幻觉率上涨推送钉钉/企业微信权限项目管理多项目隔离、版本管理模型版本、知识库版本、Prompt版本技术选型采集层OpenTelemetry 自研SDK封装消息队列Kafka削峰接收高并发Span事件时序指标Prometheus Grafana负责基础指标Trace存储ClickHouse适合存储海量半结构化Span日志查询链路明细数据库PostgreSQL存元数据、评测集、标注信息、项目配置后端Python FastAPI前端React评测执行Celery异步任务批量跑LLM-as-Judge评测任务缓存Redis评测任务状态、限流15. 为什么传统APMPrometheusGrafana不适合LLM应用可观测Langfuse解决哪些痛点传统APM不足传统APM侧重结构化指标不保存输入输出文本Prometheus只存数值指标耗时、错误码不会存储prompt、模型回答、检索文档。LLM问题大多是内容质量问题幻觉、答非所问不是接口报错没有文本就无法定位。Span维度简单无法表征LLM业务链路普通服务是接口调用链LLM应用是多步骤语义链路Query改写→检索→重排→生成。传统APM没有原生支持RAG/Agent语义Span。缺少评测能力Prometheus只做监控没有LLM-as-judge、评测集、人工标注、质量指标幻觉率、忠实度。指标维度不匹配LLM缺少token消耗、输入/输出token、模型版本、知识库版本、检索文档列表这类LLM专属维度。Langfuse解决的核心痛点原生支持保存Prompt、模型输出、检索上下文整条Trace带文本可直接看模型回答内容原生支持RAG/Agent分层Span可视化DAG链路内置评测能力支持人工打分 LLM-as-Judge自动评测可绑定到Trace自动统计token消耗、成本估算区分输入输出token样本采样线上失败样本自动入库支持人工标注标注数据可用于微调/评测集回流多版本管理Prompt版本、模型版本方便对比不同版本质量差异#4. RAG链路Query改写 → 向量检索 → 重排 → LLM生成Langfuse分层埋点Span关键字段整个RAG一次请求对应1个Trace4个子SpanTrace根节点整个RAG会话Span1query改写Span2向量检索Span3重排RerankSpan4LLM生成每个Span必须记录的关键字段公共字段所有Span都要有trace_id、span_id、parent_span_id、start_time、end_time、latency、status成功/失败、error_msg、metadata模型版本、知识库版本、用户id、环境Span1Query改写query_rewriteinput原始用户queryoutput改写之后的查询文本metadata改写使用的模型名、prompt模板版本Span2向量检索vector_searchinput改写后的queryoutput召回文档列表doc_id、文档片段、向量相似度分数、topN数量metadata向量库名称、向量模型名称、召回topK阈值Span3重排 rerankinput向量检索返回的文档列表 queryoutput重排之后排序后的文档列表每个文档的rerank分数过滤掉的文档metadatarerank模型名称、重排过滤阈值Span4LLM生成llm_generationinput最终组装的Prompt系统提示词 重排后的上下文 用户queryoutput大模型返回答案token_usageinput_tokens、output_tokens、total_tokensmetadataLLM模型名称、temperature、top_p、prompt版本额外Trace根节点层面保存最终用户原始query、最终模型回答、本次链路全部检索文档可直接绑定Judge评测。
