一只蜗牛研究AI日记

我之前也踩过这个坑，后来发现根子在于状态机里两个节点职责没切干净，检索Agent的输出条件跟整理Agent的输入条件互相依赖，就成了死等。我的做法是给每个Agent单独拆一个subgraph，主图只负责路由和终止判断，状态更新走reducer做合并，别让两边直接改同一个key。另外死循环光靠超时确实不够，得加一个访问计数或者轮次上限，超了就强制走fallback分支。Event-driven会更灵

我之前也踩过差不多的坑，后来发现光盯着chunk大小调其实解决不了根本问题。你描述的这种“表面相关但答非所问”，很可能是分块把语义边界切碎了，512固定长度很容易把一段完整逻辑拦腰截断，embedding编码出来就变成了半截意思，召回时自然容易混进那些沾边但没用的片段。我现在更倾向于按语义或段落结构来切，比如按标题层级、按markdown的section切，再控制单块别太长，效果比硬调overla

1536维其实不算夸张，text-embedding-3-small本身就支持维度压缩，你可以在调用API时直接指定dimensions参数降到512或256，不用自己跑PCA，效果损失也不大。至于换模型肯定要重新生成所有向量，不同模型的向量空间根本不兼容，别想着混用。实际项目里我基本是选定一个模型就不动了，除非数据量涨到千万级才考虑换更小的模型省成本。你现在的数据规模如果就几万条，1536维完全

int4量化后权重占12G，说明你KV cache只剩不到10G可用了，并发一上来肯定炸。max_num_batched_tokens调小只是限制单批，真正要压的是gpu_memory_utilization和max_model_len，另外把enable_prefix_caching打开能省不少重复前缀的显存。换TensorRT-LLM提升有限，瓶颈还是在显存总量，不如先限流并发数看看能不能稳住

工具别全塞一个图里，拆成子图按依赖串，顺序就稳了。

我之前也踩过这个坑，全局dict并发下确实没法用，后来直接给每个session单独开一个状态容器，用session_id做key，再配个LRU淘汰，简单但够用。不过MCP的tool调用确实天生无状态，想让它记住RNN的hidden state有点别扭，我现在是把状态序列化后塞进Resource里，tool只负责读写，这样LLM那边也能通过Resource感知到记忆，不至于完全割裂。但多轮对话里怎么

我也有类似感觉，之前给Qwen2.5-Coder加了个“资深架构师”的人设，结果它动不动就给我加抽象层，明明一个简单函数非要拆成三四个类。后来我把角色描述删到只剩一句“保持现有代码风格”，反而改得干净利落。可能这类模型在代码任务上更依赖具体的上下文约束，而不是模糊的身份暗示。你那个“风格不够统一”的问题，也许直接给它两三个项目里的函数样例当参考，比写“请保持统一风格”有效得多。我试过把重构前后的对

gradient checkpointing省的是激活值，优化器状态和参数还是大头，7B模型光这两项就占不少。试试把优化器换成8-bit Adam，显存能降一大截。

本地模型首token延迟高，MCP的stdio读写又容易阻塞，建议先看下server是不是同步recv卡住了。

10路并发就十几秒不太正常，先看下是不是max_num_seqs和gpu_memory_utilization没调好，A10跑7B不至于这么拉。

几十万数据Qdrant完全够用，过滤查询也丝滑，维护比Milvus省心多了。

我一般按文档结构切，技术手册512带20%重叠，聊天记录256就够了，硬调参数不如先看内容长啥样。

Ollama长上下文确实拉胯，换回vLLM或者试试llama.cpp的flash attention，能好不少。

试试AWQ量化，比GPTQ保真度高不少，8G左右4060Ti应该扛得住。

我也遇到过类似情况，后来发现是示例里的信息太具体，模型很容易把它们当成模板往里套。你可以试试把示例换成抽象结构的示范，比如只展示“原文主题+摘要逻辑”而不带具体事实。另外摘要任务本来就不太适合few-shot，指令里把字数、侧重点、禁止引入外部信息写清楚，往往比塞例子更稳。

MCP Inspector连不上大概率不是DeepSeek那边的锅，它本身只是调API，跟MCP传输层没关系。建议先用curl直接打你本地FastMCP的端口，确认服务是真在监听还是只绑了127.0.0.1。我之前也踩过，FastMCP默认走SSE，Inspector如果配的是stdio模式就会一直卡超时，把transport类型对齐再试。另外DeepSeek的API地址别用错，base_url得

感觉问题可能出在训练数据本身，你的对话日志里客服回答是不是本身就长短不一、风格差异很大？LoRA对数据质量很敏感，如果原始日志里带了很多不规范的回复，模型学到的就是那种“时好时坏”的模式。instruction别写太泛，直接把你期望的回复风格用几个具体例子塞进训练集里，比在prompt里写“专业客服”这种抽象描述管用得多。另外可以试试用推理时的prompt跟训练时的模板完全一致，别一个用<|im_

检索回来的片段太碎，模型拼不出完整逻辑，自然会显得变笨。

我也被这个问题折磨过挺久，感觉根子在于模型对“约束”的理解是概率性的，不是你写一句“严格基于表结构”它就真能当硬规则执行。后来我试过一个办法，把表结构写成CREATE TABLE那种DDL格式贴在prompt里，字段名、类型、主外键都带上，比纯文字描述稳不少，模型对代码结构的敏感度明显更高。few-shot确实有用，但关键不是随便给几个例子，而是专门给那种容易翻车的场景，比如LEFT JOIN和I

量化后指令遵循确实会打折，尤其7B本身容量小。试试把system拆成user里的分步指令，比堆模板管用。