阿南Dev手记

MCP这层基本不背锅，它只负责透传，检索飘多半还是chunk切得碎或topk太大，试试调小topk看还稳不稳。

我最近也踩过这个坑，后来干脆不靠prompt硬控格式了，直接上OpenAI的function calling或者Claude的tool use，把schema丢给API，模型自己就知道怎么吐结构化数据。如果模型不支持，那就在外面包一层json repair加自动重试，解析失败就把错误信息塞回去让它重写。换模型确实头疼，所以最好把解析层写得宽容一点，别指望模型每次都完美。

试试把检索结果作为工具调用的前置依赖写进schema，光靠prompt模型确实容易漏。

我也踩过这个坑，感觉不是Cursor不行，而是后端接口这活儿本身就比前端组件“上下文密度”高太多。前端组件你描述清楚UI和交互，AI基本能猜个八九不离十；但后端一个更新接口背后牵着表结构、事务边界、并发场景、权限模型、异常码规范，这些东西没在代码库里沉淀成明确模式的话，AI只能靠猜。我现在的方法是先让它读几个已有的同类接口，明确告诉它“照着XxxService里的写法来”，比纯文字描述需求稳得多。

参数传错多半是schema描述不够直白，把日期格式和字段含义写进description里试试。

我之前也踩过这个坑，Recall涨了不代表端到端就好，检索和生成的目标其实不完全一致。你这情况大概率是负样本太“软”了，模型学到的边界把那些语义相近但业务上没用的都放进来了。可以试试在负样本里掺一些真实的困难负例，或者干脆加个重排序模型卡一道。另外三个epoch可能有点多，小数据集上微调Embedding很容易过拟合，先降到一两个epoch看看。

测试集和真实提问差太多才是主因，先拿线上真实query重跑评估吧。

模型小确实差距不大，但上TensorRT后大模型吞吐能翻好几倍，显存也省不少。

这问题太真实了，我们之前也踩过一模一样的坑。后来发现关键不是chunk调多大，而是得按调用链去切，比如一个函数连带它依赖的接口和工具类打包成一块，哪怕跨文件也要拼起来。再配合轻量rerank按调用关系打分，比单纯调大窗口管用多了。你们代码库要是模块化清晰的话，可以试试从入口函数反向追溯依赖树来构造上下文。

4bit微调掉点挺正常的，LoRA本身还能救回来一些，但你要是量化完还开着bf16再叠加梯度检查点，显存其实省不了太多。建议先试gradient checkpointing加flash attention 2，再把batch size压到1配合梯度累积，5万条数据的话学习率也得调低点。bitsandbytes那个4bit加载慢是正常的，推理延迟换显存嘛，效果飘可能是LoRA rank设太高了，试试

先加个reranker试试，几千条数据用IVF_FLAT有点亏，换HNSW或者直接暴力搜都行。

5000条数据训7B的客服场景，其实量不算特别少，但loss震荡不降大概率不是数据问题。rank16只挂attention可能容量不太够，客服问答往往需要模型适配特定话术和知识，建议试试把mlp层也加上，或者rank提到32-64看看。另外loss不降不代表没学到东西，生成不稳定可能跟推理时的temperature和repeat_penalty有关，先固定解码参数再评估。还有检查下数据里有没有大量

例子两三个就够，多了真会照搬句式，我一般只给一个正例加句风格指令，反例反而容易让模型跑偏。

块切太粗了，年假和调休本来就挨着，模型哪分得清。试试按小标题切，再加个重排模型过滤下。

这坑我踩过，说实话MCP的prompt确实没法硬保证工具调用顺序，它本质还是让模型自己决定下一步动作，system prompt只是提高概率，不是强约束。你写“必须”“依次”这些词，模型在简单场景下会听话，但一旦上下文变长或者工具描述有重叠，它就容易自作主张。而且很多客户端是把工具列表一次性丢给模型，模型看到两个都能用，并行调用或者先调哪个完全看它当时怎么想的。想要稳定顺序，最靠谱的还是客户端代码

我之前也踩过这个坑，大概率是 stdio 启动时 Python 环境没对上。你在 config 里写的 command 最好用绝对路径的 python，或者干脆用 uv run，别指望 Claude Desktop 继承你终端里的 venv。还有个隐蔽的点是 server 启动后往 stdout 打印了日志，MCP 会把它当成协议数据直接搞崩，日志记得全丢 stderr。先在终端手动跑一遍同样的

3e-4对LoRA来说确实偏高了，我一般从1e-4或者5e-5起步，7B模型更保守一点。loss在0.8到1.2震荡不一定是格式问题，500条数据本身波动就会比较大，batch里样本差异一大会看到这种抖动。你说的instruction/output格式其实能跑，但基座模型没经过指令微调，最好还是套个简单的prompt template，让模型知道哪部分是输入哪部分是输出。另外建议确认一下loss是

24G跑FP16的8B确实挺极限的，权重就占16G，剩下那点显存给KV cache根本不够分，长上下文一上来必炸。你观察到的量化掉质量其实挺典型的，4bit对代码任务伤害比对普通对话大，因为代码生成对token的精确性要求高，量化误差累积几步推理就崩了。vLLM那个延迟问题，多半是PagedAttention和continuous batching的调度策略导致的，它优先保吞吐，单请求排队等bat

80万数据才72%召回，大概率是切块太碎了，512对中文语义有点短，试试1024加更小重叠。

跨页问题确实很典型，固定512字符分块切断了语义边界，售后流程和保修政策很可能落在两个不相邻的chunk里，检索时只能命中一个，另一个因为embedding相似度不够被排到后面去了。你可以先别急着换语义分块，试试按标题层级切，产品手册一般有章节结构，用MarkdownHeaderTextSplitter或者自定义按“##”切，效果会好很多。top_k调大没用是因为噪声也进来了，不如在检索后加个re