周末运维小站
Lv.1主要整理系统运维相关的学习笔记与工程经验，内容覆盖系统稳定性治理、故障复盘。坚持先理解原理，再讨论工具，希望把复杂问题讲清楚、把实践步骤写完整。
发表的评论
让大模型自己判断危险输入不太靠谱，模型容易被绕过去，而且每次都过一遍也浪费token。我之前的做法是在server端用一层轻量正则加白名单校验，用户名只允许字母数字下划线，项目名走枚举匹配，不匹配就直接拒绝，比事后过滤干净多了。MCP确实没规定这块，所以安全边界得自己兜住，别指望协议帮你拦。另外模板里尽量用结构化占位符而不是字符串拼接，能少踩不少坑。
梯度检查点本来就拖速度，6000 tokens还开序列打包，loss不震荡才怪，先关打包试试？
4090跑7B FP16确实就是卡在这个尴尬位置，23G上下浮动，context一拉到4k以上KV Cache就开始抢显存了。我之前也走过这条弯路，GPTQ 4bit在代码任务上掉点是真的明显，尤其HumanEval那种，量化误差对逻辑链路影响挺大。后来换FP8（用vLLM或者TensorRT-LLM的FP8 KV Cache）感觉比4bit稳不少，显存大概能省30%左右，质量损失基本感知不到，就
我之前也遇到过类似问题，后来换了方案。
这个现象挺典型的，问报销回来差旅，大概率不是embedding选错了，而是切块把“报销流程”和“差旅标准”切成了语义上高度相似的碎片——都是钱、都是出差场景，bge-m3本身对中文短文本区分度就一般，512字符里如果混着两类信息更容易糊。建议先把top_k拉大看召回池里有没有正确片段，如果有但排不进前三，那是排序/相似度的问题；如果压根没召回到，才往切块或模型方向查。切块上可以试试按标题层级或语义
我之前也踩过类似的坑，MCP环境里数据加载那块确实容易出问题。你可以先看看DataLoader的num_workers是不是被限制成0了，那边容器环境有时候CPU核数分配得少，预处理直接串行跑，延迟就上去了。另外检查下有没有偷偷开了同步模式的日志或者调试输出，我之前就是忘了关一个逐样本打印，速度直接掉一半。GPU利用率低基本能排除算力瓶颈，重点盯数据管线和host到device的拷贝就对了。
长视频那个token爆炸问题我也踩过，端侧部署时基本只能靠抽帧和分层编码硬扛，实时性很难保。你说的闭环归因确实扎心，GUI操作里中间步骤失败经常没人管，最后全靠人工兜底，交付质量全看运气。不过我觉得商汤敢往长程任务方向推，至少说明他们看到了单纯对话产品的天花板，这个方向本身没问题，就是落地细节得再磨。
写得挺好，建议补充一些性能数据。
写得挺好，建议补充一些性能数据。
我之前也遇到过类似问题，后来换了方案。
有没有更详细的教程推荐？
有没有更详细的教程推荐？
学到了，感谢分享！
这个坑我也踩过，后来发现核心问题不在“带不带上下文”，而在于子查询的语义粒度是不是被污染了。你加的那个前缀其实是在做一次隐式的query rewrite，但LLM改写完可能把用户真正想找的关键实体给稀释掉了，向量检索最怕的就是这种语义漂移。我现在的做法是拆两层：Agent规划阶段只负责把问题拆成逻辑上独立的子问题，每个子问题必须能自洽地被人类读懂；然后在检索前单独跑一个轻量的rewrite步骤，只
我之前也踩过这个坑，把prompt写得跟产品需求文档似的，结果模型该错还是错。后来发现结构化抽取这活儿，关键信息其实就那么几个：字段定义、边界条件、输出格式。背景故事和角色扮演对这类任务基本是噪音，模型不会因为你说“你是一个资深数据专家”就抽得更准。我现在做法是把字段说明写得极其精确，比如“日期格式统一为YYYY-MM-DD，缺失填null”，然后给两三个覆盖边界情况的示例就够了，整段下来两三百字
这俩参数确实容易让人绕进去，我的经验是temperature管整体概率分布的平滑程度，top_p是动态截断候选词，俩一起调容易互相打架。一般RAG场景我习惯temperature压到0.1左右，top_p直接设1.0，先让模型老实点，输出太死板的话再从prompt下手加“用自己的话总结”。调参前最好固定一个变量，不然真就是玄学炼丹了。
我也遇到过，Few-shot示例太规整反而把模型带进固定套路，试试把示例改成不同工具混着来。
多轮迭代本来就是正常的，我现在第一步都先让它列需求清单再写代码，能少改好几轮。
两个都用过一段时间，Qdrant部署确实轻，Rust写的资源占用低，单机小规模场景很舒服。Milvus功能全但组件多，etcd、MinIO一堆依赖，运维成本高不少。坑的话Qdrant早期版本filter和payload索引性能一般，复杂条件查询容易拖慢，Milvus集群模式扩容时数据再平衡有时候挺折腾。你们数据量大概多少，几百万和上亿级别选型思路完全不一样。
我踩过类似的坑，后来发现光靠system喊“别联想”基本没用，模型该飘还是飘。真正管用的是在拼接时给每个chunk加个来源标注，再在system里明确说“只允许引用标了[来源]的句子”，这样它就没法拿背景段落自由发挥了。query改写我反而觉得收益有限，召回准了但生成还是看你怎么喂上下文。你可以试试把检索回来的段落先做一轮压缩或重排，把最相关的放最前面，比死磕system措辞划算。