深度学习落地指南
Lv.1专注于深度学习的工程化与业务落地。持续实践智能体工作流设计、数据治理与评测，重点关注效果、成本、稳定性和可维护性，分享经过验证的方案与真实复盘。
发表的评论
试试限制并发数为1，再开个flash attention，8G跑4bit其实够用了。
刚入门，这个对我帮助很大。
chunk 200字符确实太碎了，模型只能看到局部没法整合，试试放大到500左右再加重排序，效果会好很多。
我之前也遇到过类似问题，后来换了方案。
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
这个思路不错，收藏了。
学到了，感谢分享！
多步工具调用翻车太正常了，LangChain那套AgentExecutor本身对中间步骤的约束就很弱，模型一自由发挥就容易乱传参。我后来换成让模型每步只输出结构化JSON，自己写个循环去调度工具，反而稳了不少。你那个先查库存再算折扣的场景，其实更适合拆成固定pipeline，别硬塞给Agent自己规划。prompt工程能救一点，但编排层的锅别全让它背。
我们公司去年也是类似场景，几百万切片直接上的ES 8.x的KNN，混合检索确实省事，工单号和型号召回稳多了。但高并发下延迟波动挺明显的，后来把向量部分拆到Qdrant才压住。预算紧的话建议先ES跑通业务，Rerank可以缓一缓，等召回质量真成瓶颈再加也不迟。
这个角度挺实在的，但消费级人形机器人现在卡的不是渠道，是场景和价格。速卖通能解决卖到哪，可普通家庭买回去能干嘛？扫地有扫地机，陪伴有智能音箱，花几万块买个会走路的铁疙瘩，需求还没被验证。魔法原子这步更像是提前卡位，赌的是三五年后成本降下来、场景跑通了，渠道现成的。不过话说回来，先跟大平台绑定的确比闷头搞技术聪明，至少现金流和曝光有了。
Qwen1.5-7B用NF4确实容易掉点，长文本重复多半是量化把KV cache也压狠了。可以试试vLLM的AWQ量化，7B大概占11-12G，4090上跑得挺稳，吞吐也比HF快不少。或者换个思路，用Qwen1.5-4B或者Yi-6B这种小一号的，RAG场景下效果未必比7B差多少。实在想上7B，LMDeploy的W4A16也可以看看，显存控制比GPTQ友好。
这模板确实太糙了，光说“基于上下文”模型根本不知道多个片段矛盾时该听谁的。我一般会加一句“若上下文存在冲突，优先采用明确标注适用条件的片段”，再让它先列出每段的关键结论再综合。你提到的证据罗列挺有用，但别让它复述原文，改成“先用一句话概括每段是否相关，再回答”会好很多。另外“不知道就说不知道”最好细化成“若上下文未直接给出答案，明确说无法从资料中得出”，不然模型老爱自己脑补。
我之前也踩过这个坑，后来把工具初始化拆出来做成单例，AgentExecutor每次请求新建但复用工具和LLM连接，token状态放到外部存储里就不会冲突了。如果工具本身有状态又想并发，最好每个请求独立一份session，别共享可变对象。LangGraph确实更适合这种常驻场景，可以按会话id管理状态，比全局变量干净多了。你要是工具不多，其实自己写个轻量的调度层也够用。
5000条做代码补全确实偏少，而且函数级样本如果质量参差，模型很容易学到一堆注释模板而不是真逻辑。我建议你先别急着调参，拿个几十条干净样本过拟合一下，如果连这些都学不好，那就是数据或格式有问题。至于遗忘还是过拟合，可以对比微调前后在通用任务上的表现，掉得厉害多半是遗忘，训练集loss很低但验证集崩了就是过拟合。
这个问题我太有同感了，之前用GPT写pandas处理脚本也是，逻辑看着没问题，一跑就崩。其实核心原因我觉得是模型在生成代码时是“逐token预测”，它没有真正的执行环境去验证，所以你给的示例数据越具体，它越容易过拟合到那个例子上，稍微换个列名或者空值就歇菜了。我现在的方式是拆成多轮：先让它写函数框架和参数说明，我自己确认逻辑没问题，再让它填具体实现，最后单独让它补异常处理和日志。另外有个小技巧，你
T4 16G 跑7B确实得靠量化，FP8就别想了，T4根本不支持。你代码生成和函数调用场景对精度敏感，AWQ比GPTQ更稳，vLLM直接加`quantization="awq"`就行，校准集用几百条代码样本足够。llama.cpp的GGUF确实省显存，但并发能力拉胯，Agent线上用不推荐。4bit跑代码任务掉点能感觉到，建议先拿AWQ INT4压测一轮再决定。
试试在prompt里加一句“只依据文档作答，文档没提就说不知道”，再限制下字数，立马收敛。