04201. 职场学习簿

存原文吧，检索回来还得靠它拼上下文，不存的话又得多跑一趟数据库，图啥呢。

ResNet50 这种经典 CNN 开 compile 收益确实一般，它本来算子就规整，TorchInductor 能优化的空间不大。第一次慢是因为要编译图，后面快那点主要是省了 Python 开销，你这卡本身算力也有限，瓶颈更多在硬件上。真正吃 compile 红利的多半是 Transformer 那类，或者有大量小算子、动态 shape 的场景。可以试试开 max-autotune 看看，但别

仓储场景那个力控延迟碎货太真实了，我们做抓取也卡在这，50ms基本是分水岭。现在展台上那些demo换个光照就露馅，通用性吹得越狠落地越难。我觉得短期还是得往专用场景死磕，把可靠性磨出来再谈泛化，不然全是PPT。

系统提示词确实比全堆在user里管用，Qwen2.5对role区分还是挺敏感的。我一般把任务约束放system，比如“你只输出合法JSON”，然后user里只给待分类文本，效果稳很多。还有temperature不用压到0.1，太低反而容易死板重复，0.3左右配top_p 0.8试试。另外JSON可以用response_format或者引导词开头，比如直接让它以{起手，能减少废话。

切分前先按标题层级聚合段落，别直接按字数硬切；BGE换base或large，小模型召回本身就碎。

4090跑7B还OOM不太正常，试试把gpu_memory_utilization拉到0.95，max_model_len降到4096够用。

试试把工具调用拆成独立的状态机+队列吧，多工具组合时比if-else清晰多了。

显存涨这么猛确实不正常，你试试把max_tokens调小点，或者开下vllm的prefix caching看看效果？

我之前也遇到过这问题，后来把工具描述全改成“动作触发”式的，比如“当用户明确要保存内容时用这个”，比单纯列功能好用很多。另外试下把最常用的工具放到列表前面，模型有位置偏好。还有就是参数别用嵌套对象，全拆成扁平字段，错误率会降不少。换模型的话Claude对工具调用的遵循度确实比GPT-4稳，但成本也上去了，可以先优化prompt再考虑换。

这问题八成出在chunk切法上，产品手册和工单混着切，语义早被切碎了，先按文档结构切试试。

这个问题我当初也卡过，实际只用embed用户的问题去库里做相似度搜索就行，文档库是一次性提前算好存起来的。

24G跑7B LoRA其实是够的，你大概率卡在激活值上——试试把batch size降到1然后梯度累积开大点，或者检查下是不是把完整模型加载进显存了，用load_in_4bit=True配合bnb_4bit_compute_dtype=float16能直接砍掉一大半权重占用。fp16 loss慢可能是学习率没调，LoRA本身收敛就比全参慢，别跟全量微调比，建议把lr调到1e-4级别再看看。另外to

说个偏门但实测有效的思路，r和alpha的比例不是死的，关键看你的数据集有多“专”。领域问答如果数据量小但分布集中，r=8配alpha=16很容易让模型死记答案，我当时把alpha降到r的一半以下（比如r=8，alpha=4）反而稳了，相当于给更新幅度加了约束。OOM那个问题，试试gradient checkpointing或者把batch size砍半，r=16理论上不该爆的。另外你观察下验证集

说实话我觉得问题可能不在模型本身，bge-reranker-base在中文场景下不至于那么拉胯，你试试看是不是检索环节埋了雷。top20里面如果本身相关文档就没排进前20，rerank再强也救不回来，毕竟它只是对候选集做重排，不是召回。你那个300字chunk加50重叠，说实话粒度挺粗的，有些知识库的段落逻辑被切碎了，语义不完整，rerank看到的上下文就是残缺的，自然容易误判。另外Faiss用c

说实话这问题跟框架关系真不大，7B多模态这个体量，PyTorch开满优化跑不动的话JAX大概率也就多撑一两个batch。我之前试过用JAX跑类似任务，省显存主要靠的是显式函数式编程让你没法偷偷保留中间tensor，但视觉encoder那块照样得精打细算。 你这情况不如先看看是不是视觉塔和LLM的activation峰值叠一起了，试试把视觉encoder的梯度checkpoint单独打开，或者用t

之前做类似项目也卡在这，500确实太粗，200又太碎。后来我是按语义段落切，再配合标题层级做父子chunk，检索时用父块补上下文，效果比单纯调数字稳很多。embedding模型输入长度是个硬上限，但实际最优chunk跟文档结构关系更大。混合检索确实能救回来一部分，尤其专有名词或者精确数字这种，BM25匹配比向量靠谱，建议试下。

我之前也踩过这个坑，Qwen2.5-7B不带tool calling的话确实容易乱来，后来换了官方那个function calling微调版，加上强制JSON schema输出，情况好了很多。你可以试试在LangChain里用`bind_tools`，再把`tool_choice`设成“auto”看看，比全靠prompt硬约束靠谱。另外别指望一个框架通吃，工具调用逻辑复杂的话，直接手写个循环处理可

我之前也踩过这个坑，光提top_k真没用，反而把不相关的描述全捞上来了。我现在是把每个MCP工具的说明写成带触发条件和输入输出示例的JSON Schema，然后让RAG直接检索这个结构化定义，比搜自然语言文档准很多。另外建议在system prompt里塞两三个“用户问题→正确工具”的few-shot例子，模型对齐起来会快不少，你可以试试看这个组合。

我自己也踩过这个坑，大概率不是embedding的问题，ada-002对语义匹配还是够用的。你那个“售后服务流程”召回一堆参数，更像是chunk切分把流程步骤拆散了，或者PDF里表格和正文混在一起，向量化时上下文丢失。建议先手动看几段召回文本，确认是检索到的内容本身不相关，还是相关内容没被切进chunk里。预处理上可以试试按标题或章节层级切分，或者用LangChain的MarkdownHeader

八成是Claude Desktop对localhost有限制，试试绑个局域网IP或者用ngrok转发一下，我上次就这么解决的。 我也遇到过，多半是SDK版本和客户端不匹配，锁死版本再试试，新版反而容易踩坑。