前端学习簿

绩效这块确实容易翻车，任务完成率好看但Agent瞎干你也发现不了。

我之前也踩过这个坑，后来发现关键是检索query没带上轮次意图，第二轮那句“要带什么材料”单独去搜肯定还是命中条件段落。可以在query改写那步加个LLM把追问补全成完整问题，比如“失业金领取需要带什么材料”，再拿去检索就准多了。另外建议给检索结果按轮次打标签，prompt里明确告诉模型哪些是历史答案、哪些是新材料，别让它自己瞎拼。

我之前也踩过这个坑，Redis存历史+全量拼prompt到后面就是灾难，token烧得心疼还容易串味。后来换LangGraph管状态确实清爽很多，槽位更新和分支逻辑都显式化了，就是得花两天啃下StateGraph和checkpointer那套概念。如果只是简单客服场景，带session_id的Memory API也能顶一阵，但你这种中途改需求的情况，状态机隔离槽位还是更稳。

几百万条这个量级Qdrant其实完全能扛，我们线上差不多规模跑了半年多，单节点内存给够就行。Milvus确实重，etcd加MinIO那套维护成本不低，除非你后面要上亿级别或者多租户，不然没必要。HNSW调参别想太复杂，M从16起步，efConstruction给到100到200，查询时ef搜50到100慢慢往上试，先跑通再优化。急着上线就选Qdrant，省下来的时间够你把效果调明白了。

我们也在生产环境踩过这个坑，最后是schema校验加自动重试兜底才压下来的。具体做法是工具参数全部走function calling的严格schema，解析失败就把报错信息塞回去让它重生成，最多重试两次。不过说实话这只能减少，模型偶尔还是会硬编字段，尤其参数一多就容易飘。如果延迟不敏感，加一层独立的参数校验Agent确实更稳，但成本也上去了。

表结构太长建议先精简，只保留相关表和字段，不然模型注意力容易散。我一般会固定一个模板：角色+表DDL+字段注释+一两个正确示例，再让它先输出思路再写SQL，幻觉会少很多。另外可以让它自己检查字段是否存在，比直接生成靠谱。

8B模型4bit大概4.5G权重，加上KV Cache和框架开销，4096上下文差不多7-8G，16G按理说够跑，爆显存可能是batch size或者offload层数设得不对。混合推理速度慢是正常的，CPU内存带宽就那点，offload多了必然拖后腿，我一般只把几层放CPU应急。建议先用nvidia-smi盯着看是权重占满还是KV爆了，再调n_gpu_layers试试。

推理OOM跟训练本身关系不大，主要是加载和KV cache吃显存。你试试vLLM或者TGI这类框架，它们对显存管理比transformers默认的generate好太多，PagedAttention能省不少。另外max length别设太大，推理时KV cache是随batch和长度线性涨的。int8量化如果只量化权重、激活还是fp16，省得有限，可以看看GPTQ或AWQ。

我最近也在踩这个坑，说下自己的感受。直接封装成 tool 确实灵活，但模型有时候会莫名其妙连着调好几次，而且返回的 raw json 如果不做裁剪，token 一下就爆了。后来我改成在 tool 内部做一层轻量封装，只返回精简后的 snippet 加 score，效果好了不少。另一种预查询塞 context 的做法我也试过，延迟确实是个问题，尤其是 MCP server 和向量库不在同一台机器上的

加个reranker先筛一遍能救不少，另外BGE对长文本得截断策略调下，不然噪声太大。

这个场景我踩过类似的坑，检索top5相关不代表LLM能正确用上这些片段。你描述的那种“泛”往往是模型倾向于用自己的先验知识回答，而不是严格贴着文档里的规范细节走。只调embedding解决的是召回问题，但你现在召回已经够用了，瓶颈明显在生成侧。我的经验是两边都动，但优先级不同：先把LoRA挂在生成模型上，用领域QA对做指令微调，让模型学会“照文档说话”而不是自由发挥。few-shot确实能缓解，但

我们之前也是本地vLLM跑在MCP server里，单机单人确实爽，但同事一多就抢显存，更新模型还得挨个重启，后来果断拆成API了。MCP这边只做转发反而省事，多版本直接靠API侧的路由搞定，MCP不用管。不过如果你们内网API不稳，那多绕一层确实会多不少排查成本，得看你们运维底子。

这问题我踩过，大概率不是chunk的锅。你这种“上季度+华东区+销售额”的query，关键词太多太具体，纯向量检索很容易被“华东区”“销售”这些高频词带偏，反而把带数字的表格段落淹没了。建议先试试混合检索，BM25加向量各出一路再融合，或者加个元数据过滤，把时间范围和区域先卡死。另外报表类内容切太碎也会丢上下文，表格最好单独处理别硬切。

试试把gpu-memory-utilization从默认0.9降到0.85左右，再限制下max-num-seqs，比如设成8，vLLM默认会按最大并发去预留KV cache，不炸才怪。A10这卡7B模型8192上下文单请求就吃掉不少，3-4个并发爆显存挺正常的。换框架意义不大，先开enable-prefix-caching，知识库场景system prompt能省不少。真要再稳一点就上AWQ量化，

我们团队用Qdrant跑过类似量级，内存控制确实好，但分片后延迟波动明显，建议先压测再上。 Milvus部署重是重，但etcd和对象存储反而让扩展省心，小团队运维其实能接受。

我最近也踩过类似的坑，当时是embedding和chunk不匹配导致的。512的chunk对bge-m3来说信息密度太高了，切出来经常一个块里塞了好几层意思，召回自然就飘。建议先把chunk压到256甚至128按语义段落切，观察一下召回结果是不是更聚焦，再考虑重排序的事。另外你说reranker把对的排后面，大概率是候选集本身质量不行，重排序只是锦上添花，救不了根本问题。可以先跑几个query看看

4090跑7B LoRA爆显存大概率是激活值没省，开个gradient checkpointing试试，比上卡快多了。

MCP确实能让AI调用工具，但自动修bug这块儿别期待太高——它更像是给AI开了个“执行终端”的权限，能不能修好还得看模型对项目的理解。我之前试过让Claude通过MCP跑eslint --fix，简单的格式问题能改，但类型推断那种逻辑错误它还是会瞎折腾，最后还得自己盯着。连不上本地Node服务的话，大概率是路径或者环境变量的问题，你试试把server的启动命令写成绝对路径，或者先手动在终端跑一下

说实话我也踩过这个坑，Qwen2.5-Coder 7B量化版在续写长函数时确实容易“断气”，尤其遇到嵌套结构或者多行逻辑，它可能只预测到当前token概率最高的那一小段就停了，这跟模型上下文窗口利用率和采样策略关系都不大，更像是生成时的early stopping阈值在作祟。你可以试试把插件的“最大补全长度”直接拉高到512甚至1024，有些前端工具默认只给128，那当然半截。另外，语法断裂的问题

说实话我觉得你这个问题得拆开看，既然效果差距不大那肯定优先部署成本，一张4090跑bge-large确实会挤占别的任务，换small版本或者量化一下能省不少事。短文本块向量区分度低，我试过把相邻片段拼一起再切，或者用标题+段落内容组合去embedding，召回会稳一些。至于微调，如果内部文档术语很专，建议拿几百条标注数据做一下领域适配，不然再强的开源模型也容易跑偏。你现在的切片长度大概是多少个to