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

没必要在学校疯狂卷了

"线上CPU使用率突破85%，请立即处理。" 手机震动的那一刻，我从床上弹了起来。 这是我负责的模块上线后的第三天，也是我第一次在凌晨收到生产环境的告警。 我打开电脑，手指在键盘上有点抖。 监控大盘上，那条红色的曲线像心电图一样跳动着。 我深吸一口气，开始排查： 先看日志——发现某个接口的调用量突然暴增。 再看链路追踪——发现是一个查询语句在循环执行。 最后定位到代码——我上周优化的那个缓存逻辑，在某个边界条件下失效了。 "找到了。"我在群里发了条消息，然后开始写hotfix。 十分钟后，代码提交。 二十分钟后，灰度验证通过。 三十分钟后，全量发布。 凌...