TypeScript 应用上线日志分析后 RAG 问题怎么定位
当应用在接入 RAG 之后出现回答不准、响应变慢或直接报错时，日志里有哪些关键字段最值得优先排查？
先看链路标识、检索结果和模型输出
可以优先关注请求 ID、会话 ID、用户问题、召回到的文档片段、重排结果、提示词拼接内容、模型返回内容、耗时分布和错误码。通过这些信息，能快速判断问题是出在检索阶段、提示词组装阶段，还是模型生成阶段。若检索结果为空，通常是召回配置、向量库数据或分词策略有问题；若检索命中但回答偏差大，常见原因是上下文拼接、提示词约束或模型参数配置不合适；若出现超时或异常，可以结合接口耗时和错误栈定位到具体服务或依赖。
用户反馈答案不对时，如何借助 TypeScript 应用的日志快速区分是检索没召回到有效内容，还是模型生成阶段出了问题？
用日志对照检索结果和生成结果做分层判断
可以把一次请求拆成检索日志和生成日志两部分来看。若日志显示检索阶段没有拿到相关文档、召回分数很低，或返回内容明显偏离问题主题，问题大多在检索侧，可能涉及向量化质量、索引更新、过滤条件或召回阈值。若检索内容是对的，但模型输出仍然不符合预期，就要重点检查提示词模板、上下文长度、温度参数、系统指令和模型版本。对于 TypeScript 项目，建议在每个阶段都输出结构化日志，便于按请求 ID 串联分析。
同样的问题在不同时间回答结果差异很大，这类不稳定现象从日志里通常能看出哪些配置变化或环境差异？
重点比对配置、索引版本和输入上下文
应重点对比模型名称、温度、top_p、max_tokens、召回条数、重排开关、向量库索引版本、知识库更新时间以及提示词模板版本。若某些请求命中了不同版本的索引，结果差异往往来自数据更新不一致；若配置记录显示模型参数在不同环境里不一致，也会造成输出波动。还可以查看用户输入是否经过了不同的预处理，例如截断、清洗、语言识别或权限过滤，这些环节都会影响最终结果。
如果想让上线后的 RAG 问题更容易定位，日志埋点应该记录哪些内容，才能满足后续分析和追踪需求？
用统一结构化日志记录每个阶段的关键信息
建议为一次 RAG 请求建立统一的结构化日志，记录请求 ID、用户输入、检索参数、召回结果、重排结果、上下文拼接内容、模型请求参数、模型响应、耗时、异常堆栈和外部依赖状态。还可以加入知识库版本、索引版本、租户信息和灰度标记，便于判断问题是否只影响某一批用户或某一环境。对 TypeScript 应用来说，使用类型明确的日志对象能减少字段缺失，便于后续在日志平台里做过滤、聚合和链路追踪。