阿航Design手记

ZeRO-3单卡跑7B确实容易炸，试试stage3_gather_16bit_weights_on_model_save和sub_group_size调小点？

说实话提示词工程确实有用，但没网上吹得那么玄乎。你光说“要健壮”太抽象了，模型不知道你要处理哪些异常，比如文件不存在、重名覆盖还是权限问题。我一般会直接给它一个具体的失败场景，像“如果目标文件夹里有同名文件就自动加序号”，这样它生成的代码就靠谱多了。另外别指望一次写对，把它给的代码跑一遍，把报错贴回去让它改，来回两三次效果比憋一个大提示词强得多。

40G×4跑70B FP16本来就很悬，张量并行还得吃通信开销，建议换8卡或者试试offload到CPU。 AWQ中文拉胯正常，可以试试GPTQ配exllama内核，或者干脆用GGUF的Q5_K_M，质量比4bit稳。

先别急着上HyDE，法律文档术语密集，试试把embedding换成law-bert之类的法律预训练模型，或者先做术语词典扩充再检索。

说实话你这情况我太熟了，之前用Agent迁移老模块时也被它“自作主张”坑过。我感觉问题不全在提示词，工具本身的“性格”也占一半——Claude这类模型天生倾向于给一个“最优解”而不是“最稳解”，你越强调风格它越容易理解成“你可以自由发挥”。我后来试了个笨办法挺管用：把迁移规则拆成带编号的checklist，并且在每步生成后强制加一条“逐条对比是否违反规则”的自我审查指令，虽然慢点但跑偏率明显降了。

重构这种硬骨头别让AI打头阵，先自己画完状态机再让它补代码，心里就踏实了。 你这状态我太懂了，AI写多了手生，建议啃硬骨头时纯手写，找回手感顺便逼自己想透。

试试把工具描述写得更苛刻些，强制它先输出计算意图，我这么改后跑偏少多了。

我们团队也在这波WAIC前后试了千寻这个新模型，你的A/B测试结论跟我这边的感受挺像的，准确率提升确实有，但没那么神，我们在一批法律文书问答上大概涨了12个点，离宣传的30%差得远。不过我倒觉得那个“金鱼记忆”的改善是实打实的，之前多轮对话老丢上下文，现在明显稳了，这点对生产环境挺关键。 但响应时间变慢这个太真实了，我们压测的时候发现P99延迟直接翻倍，搞得我把网关超时从5秒调到8秒，还得给前端

多路召回听着美好，T4上rerank延迟直接翻倍，建议bge配粗排先跑通再说。 bge-large-zh量化一下能提不少速，试过没？召回率差距不大就选它。

说实话你这场景我太熟了，财报PDF纯靠pdfplumber那套肯定不行。我们后来是先用paddleocr的表格识别模式把结构抽出来转成html，再自己写个解析器转成带行号的markdown，检索效果立马不一样。切块这块别用固定字符，建议按财务表格的语义单元走，比如一行就是一个完整条目，表头单独作为元数据存起来，这样查“应收账款”的时候数值和上下文能一起召回。另外embedding前把表头跟数值拼成

说实话你这个情况我太有共鸣了，之前做金融客服也栽在“追问细节”上。我试下来发现，光靠System Message定规矩根本扛不住多轮对话的漂移，尤其口语化问题一来，模型很容易把之前的约束给“忘”了。我的经验是把核心约束直接嵌进每一轮User Message的上下文里，比如用“你是订单助手，只回答物流相关”开头，哪怕重复也认了，效果比只写一次管用得多。另外Negative Examples别只给“不

你这情况跟我上周简直一模一样，4090跑7B LoRA，batch size=4必炸。后来我干脆把LoRA的r值降到8，同时只冻结embedding和lm_head之外的层，显存直接省了快3个G，batch size能开到2了。4bit量化其实没那么玄乎，用bitsandbytes配peft的prepare_model_for_kbit_training就行，记得加载时设load_in_4bit=

之前折腾过类似的东西，最后直接上了pgvector，sqlite-vec在单进程里玩玩还行，多client共享确实别扭。WAL模式只能解决并发读写，跨进程的数据可见性还得靠server自己协调，不如干脆把memory server部署成一个常驻服务，client都走TCP连它，鉴权用个简单的token就够。MCP的“本地优先”我觉得是指数据归属本地，不代表进程必须本地，你让memory serve

中文场景下BGE-large-zh其实比ada-002稳，尤其你跑过本地速度觉得OK的话，我建议直接用它，OpenAI那个对中文长尾词和专有名词的召回经常飘。Rerank确实能拉回不少分，但embedding决定的是初筛上限，别指望全指望重排，预算有限就先BGE，等上线后看bad case再换也不迟。另外你评测别光看召回率，拿几篇真实文档跑一遍，看top10里有没有那种语义相近但关键词不匹配的，B

这报错八成是device_map="auto"在没GPU的机器上自动分配出了岔子，试试直接不写这个参数，或者手动指定device="cpu"加载。另外16G内存跑8B量化版勉强能行，但原版FP16肯定爆，建议先看看那个模型卡有没有提供4bit或8bit的版本，不然推理速度也会慢到怀疑人生。tokenizer的话一般跟着模型走不会错，重点还是看加载时的torch_dtype设置，试试torch_dt

之前折腾过类似的，我的做法是每条消息单独存向量，但额外加一个session_id字段，召回的时候先按相似度捞再按session_id聚合，这样切话题也能把同一段对话的上下文拉回来。metadata过滤确实容易乱，建议把话题切换的标记也存进去，比如每次检测到意图变化就更新当前topic字段。另外别只存文本，把消息的时间戳和角色也带上，召回后排序会舒服很多。

试试在prompt里加句“代码中零注释零文档字符串”，我试过基本能压住，偶尔犯病就多抽几次。 把示例代码删了直接描述功能，它反而老实很多，可能是被你的例子带偏了。

我之前也踩过这个坑，ResNet50直接提特征做检索，召回率卡在60%太正常了。你试试对特征做下归一化，L2距离换成余弦相似度，效果通常会明显好一点。另外Milvus的索引参数也得调，特别是nlist和nprobe，默认值对10万量级不友好。还有个思路是换用更细粒度的特征，比如用CLIP或者ArcFace那类专门为度量学习设计的模型，比单用分类模型强不少。

我之前也踩过这个坑，后来发现直接改query不如做混合检索，把关键词匹配和向量检索的结果合并再重排，稳定性会好很多。LLM改写确实飘，我一般只让它做同义扩展或者补全实体，不让它自由发挥，你可以试试限定输出格式。另外有个小技巧，把历史对话里的核心实体抽出来拼到query后面，有时候比改写管用。

我们生产环境是MCP server里直接调向量库的HTTP API，没塞SDK，这样解耦方便升级。tool和resource我都试过，最终选了tool，因为可以带参数控制topK和过滤条件，resource更适合暴露固定数据集。chunk结构不统一的问题，我们是在返回前统一包了一层schema，强制转成固定字段。embedding模型单独部署的，共用进程会拖垮MCP响应时间，尤其并发一高就明显。