全栈方法论

真实用户问题一进来就飘，多半是你few-shot例子的覆盖度不够，单测那几条太像了。知识库问答最容易出的就是模型拿预训练知识去补文档里没有的东西，光靠调temperature压不住。可以试试在Prompt里明确要求“只根据给定文档回答，没有就直说不知道”，再加一两句边界样例。分析工具的话，LangSmith或者promptfoo能帮你批量跑case对比输出，比纯靠感觉试靠谱些。

加个rerank再卡个相似度阈值，top5里混进无关片段模型肯定瞎编。

这问题太真实了，我去年做售后Agent时也经历过，`v3_真的最终版`这种命名简直一模一样。后来我强迫自己改成用日期加一句改动摘要来命名，比如`0412_缩短回复加退款示例`，虽然土但至少能追溯。另外我觉得光靠命名治标不治本，得把Prompt当代码管，用Git做版本控制，每次改动写清楚动机，回滚也方便。还有个坑是很多人把few-shot例子和系统指令混在一个文件里改，我后来拆成基础指令、语气规则、

3000条数据跑一个epoch确实少了点，模型还没学会你的业务逻辑，倒是先把那几句固定话术背熟了。2e-4对LoRA来说偏高了，容易过拟合小数据集，试试降到1e-4或5e-5，rank先从8或16起步。开放域变差很典型，因为LoRA只更新了低秩矩阵，基座能力被覆盖了一部分，你可以混一些通用指令数据进去，比例大概1:3。另外别只跑一个epoch就下结论，看loss曲线，如果训练loss一直降但验证l

14G确实有点离谱了，不过也不是完全没可能。vLLM的显存占用不只是权重，KV cache才是大头，尤其你没限制max_num_seqs的话它默认会按可用显存尽量多分配。A10是24G卡，vLLM启动时gpu_memory_utilization默认0.9，也就是它会主动吃掉差不多21G左右，你看到14G可能只是还没跑满或者被别的进程占了。先试试把gpu_memory_utilization调低到

PyTorch部署MCP也挺顺的，官方示例多不代表TF更稳，关键看你模型原本用啥训的。

百万级用Qdrant挺稳的，Milvus那套etcd确实折腾个人项目有点过了。

这个现象挺典型的，我之前也踩过类似的坑。你训练时4G是因为有梯度、优化器状态这些额外开销，但推理时反而涨到10G，大概率不是no_grad的问题，而是加载模型的方式有鬼。很多人保存state_dict后推理时直接重新实例化一个完整模型，如果config里某些参数跟训练时不一致，比如hidden size或者num labels对不上，PyTorch有时会静默重建导致显存异常。还有一种可能是你加载权

这个思路其实挺靠谱的，MCP做召回前的预过滤确实能砍掉不少噪音。我试过类似的路子，让LLM先通过工具查一下关键词或者元数据，再拿过滤后的query去向量库检索，垃圾chunk少了很多。不过MCP本身不解决召回语义匹配的问题，它更像是帮你把query改得更准或者缩小检索范围。要是知识库本身chunk切得烂，那还是白搭，得先看看是不是分块策略有问题。

试试在Prompt里加“只输出diff，别动其他行”，再配合Cmd+K局部编辑，基本就不乱改了。

是不是训练里把EOS token给mask掉了？模型不知道啥时候停，就容易一直重复。

分块肯定要做的，bge-large-zh对长文本确实会稀释语义，建议先按语义切到300-500字再入库。另外IVF_FLAT的nlist=1024有点大了，你数据量不大的话聚类中心太多反而召回不准，试试nlist降到128或者256，nprobe调大一点。还有检查下是不是没做query instruction，bge系列检索时query前面要加指令前缀的。

日志里没请求到server，多半是command路径或Python环境没对上，先换成绝对路径试试。

切分粒度确实得看文档结构，PDF技术手册里表格和代码块混在一起，按固定字数切很容易把上下文切碎。我之前也踩过这个坑，后来改成按标题层级递归切分，再给每个chunk加上所属章节的元数据，召回准确率提升挺明显的。reranker建议加上，先用向量召回top20再重排，效果比单纯调chunk_size好得多，速度也能接受。另外embedding模型换成bge-large这类中文强的试试，差别真的不小。

并行查所有库再让LLM合并更稳，别指望它自己选对，元数据过滤加交叉验证也管用。

24G跑7B半精度理论够用，但你开并发+offload其实挺容易触发碎片问题。我之前也遇到过类似情况，后来发现是KV cache没设上限，并发一上来直接把显存吃干净了。可以试试限制max_num_seqs或者用vLLM那种PagedAttention的方案，MCP底层调度跟transformers确实不太一样。另外看看有没有开CUDA的expandable_segments，环境变量加上PYTOR

你这情况挺典型的，索引召回和暴力检索有差距很正常，但差这么多大概率是归一化没对齐。Milvus里如果建索引时用了IP度量但向量没归一化，跟余弦相似度的结果就会偏。建议先统一用COSINE度量，确认写入和查询前都做了L2归一化，再调nprobe看看。另外50万数据其实HNSW更合适，IVF_FLAT对nlist太敏感，容易漏召回。

我也遇到过类似情况，数据处理这块AI确实容易想当然，尤其列名和路径这种上下文强依赖的东西。我后来改了个思路，不让它直接写完整脚本，而是先让它生成一个只读表头和前几行的代码，我跑完把真实输出贴回去再让它接着写。这样它就不会瞎猜了，改起来也快很多。Cursor里可以试试用.cursorrules把项目约定写死，或者干脆用pandas的read_excel加参数那几行手动写，剩下的交给它补。

24G跑8B其实挺宽裕的，OOM大概率是vLLM默认gpu_memory_utilization留太多给KV cache了，调低到0.85再试试。量化我推荐AWQ 4bit，比int8快不少而且精度掉得不多，并发场景比GGUF舒服。多卡的话vLLM支持tensor_parallel_size直接加参数就行，不用改模型代码，但两张卡之间的通信开销要看你主板走的是不是PCIe 4.0 x16。CPU

检查下自定义forward里是不是多了没必要的中间变量，那玩意儿不释放显存也扛不住。