深度学习落地指南

多步工具调用翻车太正常了，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里加一句“只依据文档作答，文档没提就说不知道”，再限制下字数，立马收敛。

我们生产环境就挂了三个，文件、Git和内部API，再多工具列表确实爆炸，模型选错的概率明显上升。我的经验是按需动态加载，比如先用一个轻量路由判断意图再挂对应server，比一股脑全塞进去强不少。连接池和超时也别忽视，之前超时设太短老是重试，反而拖慢整体响应。

固定长度分块对技术手册确实容易切碎语义，500字符可能刚好把标题和正文拆开，检索时自然抓不住重点。我之前也踩过这坑，后来改成按Markdown标题层级递归切，段落完整多了，召回质量明显提升。你可以先拿几份PDF试试LangChain的RecursiveCharacterTextSplitter，配合标题分隔符看看效果。另外检索时加个rerank模型或者BM25混合召回，也能压掉不少带关键词但无关的

先别急着换框架，问题大概率出在检索这步，“发票怎么贴”和文档用词没对齐，加个查询改写试试。

2e-4对LoRA有点高了，我一般1e-4起步，代码任务过拟合特别快。

Agent场景下KV cache增长确实比普通对话快很多，工具返回的长JSON特别占地方。我一般会把工具结果先做一轮摘要或者只保留关键字段再塞回去，能省不少。模型这块可以考虑7B级别的量化版本，24G跑起来会舒服很多。另外vLLM对多轮Agent确实不太顺手，可以试试SGLang或者直接用llama.cpp，控制粒度更细一些。

我之前也在这个坑里折腾过，后来发现光调数字没用，得看文档结构。技术文档里代码块和长段落混在一起，最好按语义切，比如用Markdown标题做分隔，代码块尽量别拆散。overlap我一般设chunk的10%到15%，太大反而会让检索结果重复。另外你说的分词问题确实值得查，tokenizer不一致会导致embedding和实际文本对不上。建议先固定一个切分逻辑，再拿十几条真实query做小规模评测，比盲

在设置里把自动应用关掉，让它只给建议，你手动确认再改。

7B微调的话LoRA基本是首选了，全参训练单卡40G确实吃力。我一般bf16加梯度检查点一起上，但ZeRO-3和checkpointing冲突挺常见的，试试换成ZeRO-2或者用HuggingFace的Trainer自带方案会稳一些。其实LoRA+bf16在40G上跑7B完全够用，batch size能拉到8以上，速度也比全参快得多。除非你任务特别依赖全参更新，不然没必要硬扛显存问题。

你这个情况我也遇到过，ReAct的prompt里如果没给明确的停止条件，模型就很容易把“调用工具”当成默认动作。可以在系统提示里加一句：一旦信息足够回答用户，直接输出Final Answer，不要再调工具。另外LangGraph里可以加个条件边，检测到回复里出现最终答案就跳去END，不用硬等max_iterations。还有个偏方是把计算工具的描述写严一点，比如“仅当用户明确要求数学运算时才调用”

这个问题其实挺普遍的，我也被Cursor推荐过`xlrd`读xlsx，后来才反应过来它早就不支持新格式了。根本原因还是训练数据有滞后，模型见过的“高频代码”很多是几年前Stack Overflow上的老答案，那个年代`xlrd`确实是主流。你在设置里选GPT-4也没用，因为底层知识截止日期是固定的，跟选哪个模型关系不大。我的做法是在项目根目录放一个`.cursorrules`文件，里面写清楚“Py