一只熊猫偶尔重构日记

几十万条这量级真别折腾Milvus，Qdrant单机够跑，等真大了再迁也不迟。 LangChain里qdrant的集成比milvus顺手多了，我当初就是图省心选的它。

这题我太有同感了，Claude有时候就是“过度热情”，你让它写循环它非要炫技。我后来试了个方法，在prompt里把代码框架先占好位，比如“函数名、参数、返回结构我都定好了，你只填具体实现”，这样它基本就不敢乱动了。另外你可以试试在它输出后加一句“请保持原逻辑，只修bug不重构”，会比一开始说更管用。至于polars那个，我也遇到过，它老觉得默认库不够酷，你得在需求里强调“团队技术栈限制”，它就会老

实测过Qwen2.5-7B在A100上，AWQ 4bit大概能压到6-7G显存，但20个实例纯属理论值，vLLM的KV cache和PagedAttention一开，实际并发到8路TTFT就开始飘了。知识库问答如果检索占时间，建议2卡各跑一个实例加负载均衡，比4卡张量并行稳，单点故障影响也小。4bit掉点看场景，实体抽取和短问答基本无感，长文本生成偶尔会丢细节，你先拿自己知识库跑个评测集对比下再定

大概率是State里消息没按角色区分清楚，工具结果要单独存，别和用户话术混一起。

这现象我太熟了，LoRA微调后领域内变强、通用能力退化几乎是标配，尤其你只喂2万条中英混杂数据，Llama3的中文底子本来就不是强项，一微调权重偏移就把原生的中文语感带偏了。你loss降到0.8其实不算低，我试过类似规模数据，loss压到0.6以下才感觉领域能力真正稳固，否则模型还在“硬记”答案，没学到泛化逻辑。关于rank=8，我觉得不是主要问题，更关键的是你数据里中文和英文的比例，如果英文QA

2000条数据上lora，loss卡2.3挺正常的，先试试把lr降到5e-5，rank提到16，看能不能往下走。 你这大概率是数据量不够加上lora秩太低，建议先扩到万条再说，换成qlora试试也行。

这几点确实戳到痛处了，尤其是token爆炸那块，我们之前做视频理解的时候也踩过类似的坑，压根不是单纯堆显存就能解决的，端侧算力一上来延迟直接没法看。不过我觉得商汤可能赌的是云端协同而不是纯端侧，但这样又牵扯到网络抖动和隐私问题，反正长程任务里每一步都得跟环境交互，反馈一稀疏，整个闭环就变成盲人摸象了，归因失败基本上无解。还有就是你说的拆成独立工具调用，我反而觉得这才是现在更务实的路线，哪怕多写点胶

rerank确实能救，我之前top_k直接砍到5再加个bge-rerank，效果比调prompt明显多了。 试试把检索改成混合召回，关键词+向量一起上，再让LLM按段落置信度筛选，比单纯调top_k靠谱。

我之前也被这个折磨过，后来试了个笨办法：先按段落切，然后把段落里超过500 token的再按句子拆，低于150 token的跟下一段合并，效果比纯固定值好不少。overlap我一般设chunk的10%-15%，主要为了保住跨段的上下文，但别超过20%，不然重复信息太多反而干扰语义。工具的话可以看看langchain的RecursiveCharacterTextSplitter，配合tiktoken

量化确实会损失一部分指令跟随能力，7B本来就不算大，官网那个可能是更大参数或者做了对齐优化。你可以试试把system提示词写得更结构化，比如明确说“必须输出三条，每条不超过20字”，比单纯“提取三点”管用得多。 另外Ollama的上下文窗口默认可能比较小，如果输入文档长，模型容易“忘”掉指令，调大num_ctx试试。实在不行就用Qwen2.5-14B的Q4量化版，体感比7B稳一大截，显存够的话值

遇到过类似的，但我是四卡，NCCL卡在初始化多半不是MCP跟DDP不兼容，先试试把MCP的通信线程数调低或者干脆关掉它让PyTorch自己管，我这么改完就好了。另外检查一下网卡绑定，8卡4090如果走PCIe switch，NCCL默认的P2P可能跟MCP抢带宽，设NCCL_P2P_DISABLE=1走共享内存试试，虽然慢点但稳定。你日志里没报错很正常，这种死锁经常是静默的，可以开NCCL_DEB

这问题我调Qwen系列的时候也踩过，vLLM默认的continuous batching对7B这种小模型反而容易吃满显存但吞吐上不去，因为prefill和decode混在一起时调度开销占比大。你可以试试把--enable-prefix-caching打开，再手动把--max-num-batched-tokens调小到4096或8192，别让batch塞太满。另外单卡A100跑7B完全不用上TP，先

说实话你这个情况我太懂了，之前我搞Agent也栽在这上面。工具一多，模型就有点像选择困难症，尤其是GPT-4这种偏保守的，有时候会为了“安全”硬选一个最泛用的工具，比如你那个查天气的，可能因为它描述里写了“通用查询”之类的词，导致“记笔记”被误判成查询需求。我觉得问题不一定全在prompt，工具描述的结构也很关键，别光写“做什么”，要写清楚“什么时候用，什么时候绝对不用”，最好每个工具都加个反面例

LoRA亲测能缓解不少，但数据比例建议按任务难度调，数学和代码少点，客服多点试试。 我试过把通用数据提到50%再加回放，效果比单调学习率强，你可以试试动态采样。

我觉得问题大概率不在Embedding模型上，bge-large-zh-v1.5对细粒度语义的区分能力已经够用了，512的chunk对报销这种主题其实偏大，容易把差旅和日常报销混在一个片段里。建议先试试把chunk缩到256左右，同时按文档结构切分，别死板按字符数来。reranker倒是值得加一个，尤其TopK拉大之后，它能帮你把真正相关的片段顶上来，比单纯换模型见效快。另外也可以查一下是不是检索

同感，AI写代码就是前期爽后期还债。它特别擅长在旧逻辑上打补丁，因为训练数据里“兼容性”优先级太高，反而牺牲了可读性。建议你试试先自己把核心接口的边界定死，再让Cursor只填方法体，别让它碰整体结构。另外重构这种活儿真别指望它，让它改十次有九次是越改越复杂，不如自己花半小时重写一遍关键类，顺便把单元测试补上，后面改起来心里才有底。

说实话你这个情况太典型了，我最近也在搞类似任务，后来发现光调prompt不如在输出端做结构化兜底，比如强制要求JSON模式或者用函数调用，能解决大部分格式不稳定问题。另外建议你建一个测试集，固定几十条样本，每次改完prompt跑一遍对比准确率，别靠感觉。工具的话可以试试PromptLayer或者LangSmith，能记录不同版本的实际输出，比手动截图对比高效多了。核心思路就是别追求一次完美，把pr

我之前也踩过这个坑，光靠prompt约束顺序真的不稳，模型一长就容易自作主张。后来我是把每个步骤的输入输出都塞进结构化JSON里，比如让Agent先必须返回提取字段的JSON，再基于这个JSON做比对，相当于用数据流卡住了流程。LangGraph那种方式更硬核，但如果你不想引入太重的东西，可以试试在每步前加一个“确认”节点，让模型输出个标记，比如“提取完成，进入比对”，再配合few-shot，至少

跟你情况挺像的，后来我发现问题不在prompt多长，而是把“角色设定”和“约束”混在一起反而干扰模型判断，试着把核心指令拆成独立段落、每个约束配一个正反例，效果比堆一堆规则稳很多。另外建议给few-shot加个“错误示范”，模型有时候是因为模仿了例子里的隐性错误才飘。工具的话可以试试Langfuse或者OpenAI的evals，能看具体哪类输入触发幻觉，比盲调温度有用。

我刚开始用Cursor时也踩过这坑，后来发现光在prompt里写限制不够，得在项目根目录放个.clinerules文件，把“禁止引入新依赖，只能用现有package.json里的库”写进去，效果立竿见影。另外试试在生成前先让它看一眼你的依赖列表，或者直接给它你的package.json路径，它就老实多了。