南窗点灯

3:1太高了，模型肯定偷懒背答案。试试降到1:1，把检索片段拼进输入让它学会看。

长文档建议先按章节切块提取再汇总，或者用JSON模板强约束输出字段，效果会稳很多。

说实话这类非结构化文档解析，AI编程助手翻车太正常了，我试过类似场景，它擅长写通用逻辑，但一遇到扫描件OCR和跨页表格这种“脏活”，光靠提示词根本喂不饱它。建议你把解析拆成两步走：先用专门的文档解析库（比如PyMuPDF、pdfplumber）把结构和文本抽出来，再让AI只负责写切分策略，这样能大幅减少它自由发挥的空间。另外提示词里别给示例代码，直接给边界情况的输入输出对，让它照着修，比描述规则管

我们项目直接拆两个index，短期单独存，过期就归档进长期库，检索时先用短期再兜底长期，效果比混着强多了。

3060 12G跑ResNet50开32确实容易爆，混合精度加梯度累积直接解决，别怀疑代码。

显存没跑满但崩了，大概率是显存碎片化或者KV cache爆了，试试把max-model-len调小点。 用4bit量化加vLLM的continuous batching，7B跑agent完全够，问题多半在prompt模板把上下文撑爆了。

说实话rank的影响在指令数据比较充足的时候确实会被稀释掉，5万条代码生成任务对8B来说不算难，模型本身能力就够，微调更多是风格对齐。我之前试过rank=16和rank=64，最后BLEU就差0.3，倒是alpha调大容易过拟合。rsLoRA那种缩放方式在低rank下更稳，但你要是试到64了其实差别不大。建议直接跑个全参数微调对比一下，如果效果也就那样，那说明瓶颈不在PEFT配置上，可能得看看数据

我之前也踩过类似的坑，尤其是口语化追问一来，模型就自己“跑偏”了。后来我试了下把“你是客服”这类身份约束从System Message挪到每个User Message的末尾，比如加一句“基于上述订单信息直接回答”，效果确实稳了不少，你可以试试看。另外Negative Examples别堆太多，挑两个最典型的就够，多了反而干扰模型对主任务的判断。还有个问题想请教下，你Few-shot里的示例是单轮还

这问题我踩过一模一样的坑，大概率不是框架的锅，是你代码里某个循环变量悄悄被graph记住了。我之前跑强化学习也这样，后来发现是loss.backward()里产生的临时节点没清干净，建议你试试把推理部分包在torch.no_grad()里，然后每轮强制del掉中间变量后调用gc.collect()，再empty_cache，显存曲线能平缓很多。子进程隔离倒是终极方案，但开销太大，先排查下是不是某个

我之前也踩过类似的坑，后来发现大概率不是prompt单独的问题，而是微调数据里工具调用的格式和推理时用的系统提示词没完全对齐。你那个“city:北京”的例子挺典型的，模型可能其实学会了输出JSON，但键名或者值格式跟你在数据里标注的不一致，它只是死记硬背了训练样本里的pattern。建议你检查一下训练时每条tool_call的输入输出是不是严格按照MCP协议里的规范写的，特别是参数嵌套和类型标注，

我们之前也踩过这坑，尤其是模型脑补参数那块，后来干脆在prompt里把每个工具的schema贴全，再加一层pydantic校验，不对就直接把报错信息喂回去让它改，比光try-except强多了。重试次数设个上限，超过就降级成让用户确认或跳步，别死磕循环里。状态机倒是不必上，但每步工具的输出我会固定抽成个中间变量传给下一步，相当于软约束，体感稳定不少。你们现在重试是每次都让模型从零看全链路还是只回放

几千条数据走MCP传训练集是真不合适，协议和延迟都卡脖子，老实本地脚本更稳。

显存翻倍多半是batch size翻倍直接导致的，跟num_workers关系不大，建议先监控一下训练时的实际占用确认瓶颈。

这问题太真实了，法律条文本身就是分位阶和适用场景的，RAG只按相似度拼top-k必然踩坑。我试过在检索后加一道“法律效力排序”的过滤规则，比如宪法>法律>行政法规>司法解释，再让LLM按这个顺序取舍，效果比直接拼接好很多。另外，你可以在prompt里强制要求“若条文冲突，必须说明适用前提并给出倾向性结论”，这样至少不会把矛盾甩给用户。你可以试试看，代价是偶尔会漏掉一些特别具体的行业规定，但整体可信

你这数据量其实不用太纠结，384维在10万chunk这个规模上检索速度完全够用，准确率差距也没想象中大，bge-small调好分块和召回参数可能比换模型更有效。真要换768的，Milvus那边得重建索引，但数据不用重新embedding，存两套向量字段就行，切换时用collection分区或者别名指向新索引。我自己试过，从384升到768对长尾query有点帮助，但也就几个点的提升，建议先拿现有数

千万级768维这个量级，延迟抖动大概率不是引擎本身的问题，更像是在standalone模式下磁盘IO或者内存淘汰策略触发了瓶颈。Qdrant的接口确实省心，但Milvus胜在生态和索引参数可调性，比如试试调大`chunk_size`或者换HNSW的M值，看看能不能把尾延迟压下来。另外想确认下，你测试时Qdrant是默认配置还是也做了调优？我有点怀疑docker版默认参数在千万级上同样会吃性能，只是

大概率是负样本太简单了，随机采的让模型学不到区分度，换点hard negatives试试。 另外微调时学习率调小点，别把通用语义彻底冲掉了，加回通用语料混合训练也行。

能稳定解决自己工作里的实际问题就算入门了，进阶就看能不能把复杂任务拆成一套可复用的提示词模板。

2000条数据确实太少了，LoRA吃数据挺狠的，建议先拿原版跑个baseline对比下，说不定问题出在数据质量上。

试试让它先列代码结构再逐段补全，我之前这么搞基本一次成型，少库问题也少了。