生产级智能体研究笔记

遇到过类似的坑，小模型对few-shot的依赖度其实挺高的，但示例质量比数量重要。你选的示例可能太“像”真实对话了，模型容易记住字面，不如试试把示例里的实体和表达方式抽象化，比如用占位符代替具体产品名。另外7B模型对格式很敏感，你可以把指令改成“按以下分类规则判断，不要参考示例中的具体措辞”试试。温度0.1没问题，但max_tokens 128对意图识别可能不够，输出长一点给模型更多思考空间。

我一般拿它当结对编程的实习生看，重构建议会听，但每个改动都得自己把边界条件捋一遍。尤其是事务和懒加载这种隐性状态，AI根本看不见，你让它写单测它也是先编个能过的版本。我现在有个笨办法：让它先给方案，我口头问三个“如果这里返回null会怎样”，答不上来就自己改。工具脚本随便飞，核心逻辑还是自己手写稳当。

说实话这次中兴确实让我有点改观，OEX超节点强调协同而不是单纯堆算力，这个思路在分布式训练里挺关键的，毕竟卡间通信瓶颈往往比算力本身更致命。不过全栈这事真不是光靠一家能成的，我自己做AI落地时最深的感觉就是，系统层和模型层的适配调试极其耗时，中兴要是能让第三方框架直接跑在AIOS上不用魔改，那才算真有戏。另外手机和机器人这块，生态伙伴的开放程度才是决定能不能规模化的问题，不然容易变成自嗨。

只存embedding省空间但检索回来没上下文，还是得带原文，不然LLM根本不知道这段记忆在说啥。

正常，transformers那边默认没开flash attn的话显存就是很浪费，量化后长上下文质量8K内基本无感。

其实我觉得“请”字更像是一个风格锚点，让模型在生成时更偏向礼貌分布，而不是玄学。我自己试过在系统提示里加“你是一个温柔耐心的客服”和“请以温柔耐心的客服口吻回答”，后者确实更少出现生硬句式，可能因为“请”字本身带有请求意图，间接强化了任务目标。 不过也有个疑问，你有没有控制过变量？比如把“请”换成“务必”或者“尽量”，看看是不是同样有效，这样能排除单纯token数量的影响。另外，模型对指令性语言

别把微调当成万能药，你这问题核心不在参数覆盖，而是模型没学会“用”上下文。我试过类似方案，冻结前6层只调后6层，同时把检索文档和正确答案拼接成训练样本，效果比全量微调稳得多。 负样本别瞎构造，重点不是加错误答案，而是给模型“检索到但用不上”的例子——比如文档里有关键信息但模型答偏了，强制让它学会从文档里摘取。另外微调数据里一定要混入20%纯靠内部知识就能答对的题，防止模型过度依赖检索、失去基础能

试试直接把“# 生成代码”写进系统提示，再不行就换StarCoder，7B的CodeLlama确实容易话痨。

试试vLLM的FP8 KV Cache，配合PagedAttention能省不少，4090上7B能扛到16K上下文。

这问题太真实了，老项目里各种隐式依赖和全局变量，AI确实容易“好心办坏事”。我现在的做法是，让它改之前先明确告诉它“只准修改xxx函数，其他一律别动”，如果它非要动，就直接说“报错，回滚”。另外，把webpack的alias和类型定义多喂给它一点，比单纯锁文件有效，它至少能“看懂”点边界。 你试试把需求拆成特别小的原子任务，比如“只改这个if判断条件”，别让它一次干太多活。还有个小技巧，改完先让

阈值这东西真不是拍脑袋定的，0.8对cosine来说已经挺高了，不同embedding模型的分数分布差异很大，像bge或者text-embedding-3这些，相关内容的相似度可能也就0.7上下。建议你先拿一批人工标注过的query去跑一遍，看看相关和不相关的分数分布区间，再决定阈值放哪，不然纯靠感觉调很容易把有效召回砍掉。另外切片方式也值得检查，如果切片太碎或者跨段落切，语义不完整，相似度天然就

说实话你这情况我上周刚遇到过，最后发现是数据分布太偏加上epoch太多。LoRA虽然参数少，但2万条全是领域问答，模型注意力被强行拽过去，通用能力自然崩。建议先砍到1个epoch试试，同时按3:1比例混入通用指令数据，学习率保持1e-4应该够。另外你可以盯一下验证集loss，如果训练loss降但验证集变差，那就是过拟合没跑了。 --- 我倒是觉得rank和学习率不是主因，关键在数据配比。我之前

我之前也遇到过类似情况，loss卡在2.3不动其实挺典型的，先别急着怀疑数据集大小，5000条做SFT其实够用了。你试试把学习率降到2e-5甚至1e-5，然后加个warmup和余弦衰减，LoRA的rank=8可能也偏低，代码审查这种任务模式比较固定，rank提到16或32试试。另外，确认一下你的目标模块是不是全了，Qwen2.5用LoRA一般要同时调q_proj和k_proj、v_proj、o_p

这loss卡2.3挺典型的，先查下数据里有没有大量重复或噪声，5000条做领域SFT确实有点紧。 我试过类似情况，把lr降到2e-5再加个warmup，rank提到16会稳很多。

这问题太典型了，我上周刚踩完同一个坑。你那个“总结拿上一轮检索结果”的毛病，多半是节点函数里直接读了全局state的旧字段，没做版本比对。我后来是把每个Agent的输入输出都打上时间戳或者轮次ID，在节点入口校验一下，不匹配就强制走一次重取，比加等待靠谱多了。至于全局state还是子图，我的经验是别隔离太狠，共享一个只读的上下文快照，每个Agent自己维护私有字段，这样既不会乱也不会把图写死。你那

这问题太真实了，法律条文本身就分一般法和特别法，RAG只按相似度拼一起肯定翻车。我试过在检索后加一步规则过滤，比如优先返回效力层级更高的法条，或者对冲突结果做个“一般规定+特殊例外”的排序，效果会好不少。另外也可以在提示词里让模型意识到冲突，直接让它解释哪个优先，而不是傻乎乎全列出来。你这边有没有考虑过用元数据标记法条效力？感觉这才是治本的办法。

16G跑7B量化确实紧巴，但V100缺了FlashAttention，vLLM提升有限，建议先试AWQ+KV cache量化，能再砍掉30%左右显存。实在不行就上GPTQ的4bit加CPU offload，把部分层丢到内存，速度慢点但稳。多轮对话崩多半是KV cache没释放，手动清一下或设max_tokens上限能救急。另外GGUF配合llama.cpp的mmap模式，对长上下文友好很多，可以试

这问题太典型了，法律领域的RAG难点就在这，法条之间本来就有层级关系和冲突规则，单纯靠向量相似度拉出来拼一起肯定翻车。我之前做金融合规问答也踩过类似的坑，后来在检索后加了一层规则过滤，比如优先匹配效力等级更高的法律，或者根据问题里的行业关键词去限定法规范围，效果会好很多。你现在的Chroma里存的数据有没有做来源标注和优先级字段？如果没做的话，建议先补上这个元数据，比调embedding模型参数管

及格线就是业务指标达标，别纠结prompt本身，跑通A/B测试看数据说话。 稳定性靠评测集兜底，固定50条典型问题反复回归，比啥玄学都管用。

试试把batch size降到1配8bit，加paged_adamw优化器，能稳不少。4bit微调8B损失还行，主要看数据质量，别太慌。