1、自我介绍2、项目拷打3、RAG 的完整链路是什么，哪些地方最容易出问题RAG 的完整链路一般是文档接入、清洗去噪、切 chunk、向量化、建索引、在线检索、重排、上下文构造、Prompt 拼接、模型生成和结果后处理。线上请求过来以后，先对用户 query 做归一化处理，再进行向量召回或者混合召回，把候选文档取回来，然后用 rerank 模型重新排序，选出最相关的内容拼到 prompt 里，再交给大模型回答。最容易出问题的地方通常有几个。第一是 chunk 切得不合理，太短会丢语义，太长会导致噪声太多。第二是召回率不够，模型根本没拿到正确证据。第三是重排不准，正确文档被排到后面。第四是上下文...

求求大佬们帮忙看看简历，心态已经被磨平了，感觉自己简历问题比较大，但是不知道怎么下手改。马上要春招了，好迷茫。。。

1、实时生成的聊天代理模型，如果线上出问题了，怎么定位这种问题一般先按链路拆。如果是实时生成类聊天代理，通常一条请求会经过网关、会话层、Prompt 拼装、模型推理、工具调用、结果后处理和流式返回几个阶段。线上出问题时，先判断是全量故障还是部分故障，是所有请求都失败，还是只有某一类请求延迟高、返回空、内容异常。定位时先看监控和日志。监控上看 QPS、平均延迟、P95/P99、错误率、超时率、GPU 利用率、显存占用、容器重启次数。日志上重点看 request_id，把一次请求链路串起来，看是卡在 Prompt 构造、模型推理、下游工具调用，还是 SSE/流式返回阶段。如果是模型输出异常，要回看...