持续研究复盘实践笔记

7B模型做RAG确实挺容易卡在检索和生成两头不讨好的状态，我自己的体感是问题往往不在模型本身，而是整条链路没对齐。检索这块可以先看看embedding模型是不是太弱了，换成bge-m3或者gte这类多语言强的，召回质量会明显不一样。另外chunk切分别太机械，按语义或者段落切比固定长度好很多，不然模型拿到的上下文本身就是碎的。重排序也值得加，一个小cross-encoder就能把top结果质量拉上

7B做tool call确实容易飘，我之前用Qwen2.5-7B也遇到过类似问题，后来换了14B明显稳很多，但代价是显存和速度。其实不一定非要上vLLM，Ollama本身可以用grammar约束输出格式，你搜一下structured outputs的用法，能强制它按JSON schema走，成本几乎为零。另外prompt里把工具描述写得更明确一点也有帮助，比如直接告诉它“只输出JSON，不要任何解

工具调用这块确实和普通对话微调不太一样，我踩过类似的坑。我的做法是把工具描述直接拼进system prompt里，让模型在训练时就习惯从工具列表里选，而不是靠记忆。样本构造上，我倾向于把function call和返回结果都保留，但重点放在“为什么选这个工具”和“参数怎么填”上，尤其是那些模糊指令，可以人工标注出正确的工具和参数作为监督信号。单独做工具选择任务也不是不行，但感觉会丢掉参数生成这部分

V100 16G跑Qwen2.5-7B的GPTQ-4bit其实挺勉强的，你遇到的OOM我一点都不意外。量化确实把权重压到了4G左右，但KV cache才是隐形杀手，尤其多轮对话上下文一长，那部分显存涨得飞快，max_length调到2048也救不了根本问题。我自己用AWQ跑7B在24G卡上比较稳，AWQ的kernel对推理更友好，精度损失也小，建议你先试试换成AWQ权重。框架这块vLLM确实能帮上

这情况太典型了，loss降得漂亮不代表模型真变强了，尤其你只盯着训练loss看。法律文书和法条问答的语料分布跟通用指令差距很大，模型很容易把“回答什么都往法律语境拽”当成最优策略，结果通用能力就被挤掉了。r=16其实不算特别大，但alpha=32配上2万条高度同质的数据，过拟合的风险确实不低。我自己的经验是，垂直微调时混10%到20%的通用指令数据效果挺明显，哪怕只是简单的常识问答也能起到锚定作用

我之前也踩过这个坑，固定500字符确实容易把售后政策这种完整段落切碎，检索时匹配到的反而是高频出现的产品介绍词。建议你先按标题层级做结构化切分，把“售后政策”这类小标题单独作为chunk的边界，再控制size在200-300左右，overlap给个20%就行。另外光靠embedding不够，可以给每个chunk带上父级标题或文档类型当元数据，检索时做下过滤，效果会明显很多。

法律数据太单一了，模型很容易把所有输入都往法条上套。建议混10%-20%的通用中文指令数据进去，比例不用太高但效果很明显。学习率1e-4其实还行，我更怀疑是你3个epoch跑多了，LoRA一般1-2个epoch就够，过拟合到法律分布上了。AdamW和Adam在这个场景差别不大，weight decay对LoRA的A/B矩阵影响有限，先别折腾优化器。

我们当时也卡在选推理框架这步，最后用vLLM跑AWQ量化，效果掉得不多，吞吐比TGI舒服。Agent调外部API一定得加超时和指数退避重试，不然一个接口卡住整条链路就废了，最好再搞个降级兜底。预算紧可以先单卡起，用Docker Compose编排，别一上来就K8s，运维成本扛不住。

embedding的token不算在MCP上下文里，云端API就是单独计费。检索建议只回metadata或摘要，塞原文太吃context了。

这个问题我也踩过，光靠system prompt约束确实不太靠谱，上下文一长模型就容易忘。我现在的做法是在MCP server那层加个依赖白名单，生成完代码后先解析import再跟项目里的requirements做比对，不一致就直接打回去让它重写。另外可以试试把pyproject.toml或者锁文件塞进上下文里，让模型直接看到现有版本，比空口说"别升级"管用多了。

边界无限的RASP确实在运行时行为监控上有点东西，但AI降误报这事我持保留态度。之前测过几家号称AI驱动的WAF，实验室数据漂亮得不行，上线后业务稍微改个接口参数就疯狂误拦。RASP比WAF更贴近业务逻辑，误报代价更大，搞不好直接把正常请求给断了。长亭的AI要是真能用业务侧的对抗样本持续调优，那确实有戏，就怕最后又变成堆规则的老路子。

MCP Inspector连不上本地服务，先别急着怀疑DeepSeek那边。我之前也踩过类似的坑，FastMCP默认走的是SSE传输，但Inspector有时候得手动指定transport类型，配错了就是干等超时。你可以先拿curl直接打一下本地服务的sse端点，看能不能通，这样能快速分清是本地服务没起来还是协议层的问题。另外DeepSeek的API是标准HTTP调用，跟MCP服务本身是两回事，M

温度调低点会稳很多，另外把列名和预期输出直接贴给它，别让它猜。

在prompt里加一句“只import用到的，别加多余的”，我这么写之后好多了。

你这情况我去年也踩过，当时用 vLLM 跑 Qwen 的 function calling，一调工具就卡成 PPT，后来发现根子不在解析上。本地推理的超时经常是工具返回的数据太大，比如你查数据库直接 select * 出来几万行，模型光是把这些塞进 context 再生成下一步就爆了。你可以先看看超时是发生在模型生成 tool call 那一步，还是工具执行完把结果喂回模型那一步，这两个的锅完全不

我遇到过类似情况，问题多半出在分块上，而不是bge模型本身。合同这种文档按固定字数切很容易把违约条款和别的条款混在一起，建议试试按标题层级或语义切，让每个块尽量只讲一件事。另外query改写确实有用，把“违约金计算标准”扩成“违约金 计算方式 比例 逾期”这类关键词，召回会准不少。可以先用bge加个rerank模型过滤一遍，往往比直接换embedding提升更明显。

我也踩过这个坑，后来发现关键是把工具调用的返回结果做一次“摘要+判断”，别直接把原始文档塞回context，不然模型很容易觉得没搜到就再搜一遍。另外我加了个简单的轮次计数器，同一个工具连续调用超过两次就强制换策略或者直接说不知道。你那边有没有试过在prompt里明确写“如果检索结果相似度低于某个阈值就停止重试”？感觉比让模型自己判断靠谱。

绩效这块我也挺好奇的，Agent的KPI到底怎么算？是按任务完成率还是响应延迟？感觉很容易变成又一个拍脑袋的指标。角色冲突死锁这个问题确实真实，但平台层自动生成权限边界会不会太理想化了，实际业务里的边界往往是模糊的。多Agent系统里我更担心的是故障恢复，一个Agent挂了状态怎么迁移，这个StaffDeck有没有考虑？

这个问题其实挺典型的，我也遇到过类似的情况。Cursor默认会倾向于生成“看起来更完整”的代码结构，所以它一看到“读取csv去重”这种需求，就忍不住帮你封装几个函数，好像不这么写就显得不够工程化。但问题是它每次命名逻辑都不太一样，今天叫`clean_data_v2`，明天可能就变成`dedupe_rows`了，确实很让人头大。我后来发现，与其在注释里描述功能，不如直接给它一个明确的函数签名和命名规

口语化query直接上向量检索确实容易翻车，建议先别急着微调embedding，试试BM25加向量做混合召回，口语query里关键词匹配往往比语义更稳。重排权重拉太高确实容易把弱相关但字面相似的段落顶上来，模型看到这些噪声就爱脑补，幻觉多半是这么来的。query改写不稳定的话可以只对短query或明显口语化的做，改完还可以加个回退机制，改写结果检索不到原query的分数就弃用。排查时先分层看是召回