周末运维小站

这个坑我也踩过，后来发现核心问题不在“带不带上下文”，而在于子查询的语义粒度是不是被污染了。你加的那个前缀其实是在做一次隐式的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措辞划算。

单卡4090的话Ollama确实最省心，但它并发和长上下文调度一般，跑Agent多轮工具调用容易感觉慢半拍。我现在用vLLM加Qwen2.5的AWQ量化，函数调用基本够用，吞吐比Ollama好不少，就是启动配置稍微折腾点。长上下文这块要注意KV cache显存，24G跑32k以上得掂量下量化精度和batch。建议先用Ollama快速验证流程，跑通了再换vLLM压性能。

状态确实别全塞一个字典，拆成多个子图各自管自己的state会清楚很多。外部存储做checkpoint也值得试试。

我上次也踩了类似的坑，torch.compile 第一次跑会额外占不少显存做图捕获和缓存，24G 跑7B确实悬。reduce-overhead 主要省的是 kernel launch 开销，max-autotune 会疯狂试不同 kernel，编译期显存和时间的代价都更大，省显存反而不明显。dynamic=True 对变长输入友好，但会触发多次重编译，编译时间拉长很正常。真要省显存，先试试 mod

ReAct 在多工具串行场景下确实容易崩，本质上是每步都要重新推理全局，上下文一长就丢状态。我现在都拆成显式的状态机或者用 LangGraph 把流程画出来，每个节点只干一件事，稳定性比让 Agent 自由发挥强太多。另外工具描述要写清楚“什么时候不该用”，光写功能没用。prompt 再细也救不了架构层面的问题，早点换思路少走弯路。

你curl的是Ollama的/v1/chat/completions还是/api/generate？MCP那边调工具时走的endpoint可能不一样。我之前也遇到过，最后发现是FastMCP默认超时设太短了，工具函数里稍微多绕一层就炸。建议先把超时调到30秒以上试试，如果还卡就抓一下Ollama那边的日志看请求到底有没有进去。

loss卡在1.8还开始说套话，感觉更像是数据的问题而不是学习率。判决书和法条问答对里如果有很多相似模板，模型很容易学到“根据相关法律规定”这种万能开头，然后就不往下走了。你可以先抽几十条训练样本看看，是不是很多回答本身就重复或者太长没截断。LoRA的rank和更大模型先别急着换，把数据去重、控制长度、加点多样性问答再跑一轮，大概率比调参管用。

我最近也踩过这坑，后来发现光在prompt里喊“口语化”没啥用，得把检索片段加上来源标记和简短标题，让模型知道哪句是引用哪段。system prompt里我一般只写角色和硬约束，比如“不确定就承认”，user里再塞上下文和具体问题。还有个小技巧是让模型先复述一遍它理解的问题再答，能压掉不少啰嗦重复。你们有没有试过按查询类型切模板，比如事实型跟总结型分开？

1.5B模型加vLLM跑Agent其实够用，工具调用别硬塞进prompt，拆成两步走会轻很多。

评估体系这块确实是个大坑。现在benchmark基本都在测“理想输入下的正确率”，但真实业务里输入本身就是脏的、需求是模糊的，模型稍微遇到点噪声就崩，这种鲁棒性压根没被量化过。我倒是觉得比起重新设计评估，更现实的做法是先建一套“失败模式分类”，把长尾场景下的错误类型摸清楚，不然连问题出在哪都说不明白。成本那块也绕不开，可靠性上去了但推理成本翻倍，很多场景根本落不了地。

四五百条数据做指令微调确实偏少，尤其你想让它精准适配特定场景，模型很容易欠拟合或者只是表面模仿。可以先把learning rate调小一点，epoch多跑几轮试试，但别指望质变。数据质量比数量重要，不过这个量级下建议用LoRA降低参数量再训，效果会更稳。可视化的话可以看看wandb或者直接用eval框架对比输出分布，能看出模型到底学了啥。

这个坑我也踩过，多轮对话里指代消解确实头疼。我后来是在每轮问答结束后让模型抽一下关键实体和时间范围，存成一个结构化的小状态，下一轮直接把这个状态拼进去，比塞原始历史清爽很多。另外像“上季度”这种相对时间最好在当轮就解析成具体月份再存，不然隔两轮就彻底糊了。你们现在是用向量库存历史还是单独维护会话状态？

我之前也踩过这个坑，大概率不是GPT-2缓存的问题，而是你拼prompt embedding的方式把梯度路径切断了。最常见的情况是你用torch.cat或者torch.stack把可学习的prompt和token的embedding拼起来，但token embedding那部分可能是用model.get_input_embeddings()(input_ids)拿的，本身没问题，问题在于你可能用了

几百条对话其实没必要上MemGPT那套，维护窗口和剪枝的精力够你调好几轮检索了。我建议先给RAG加时间衰减和对话轮次权重，再补一层关键词或元数据过滤，“上次那个方案”这种指代靠纯embedding确实难搞。向量库的话Milvus Lite或者Qdrant本地模式都挺省事，Chroma小数据量够用，别太纠结性能。