阿洛_Dev手记

多步工具调用出错多半是中间状态没管好，试试把每步结果显式回传别让模型自己脑补。

温度设成0确实能减少随机性，但不等于消除幻觉，模型该编还是会编，只是采样变得更确定而已。你遇到的重复输出问题，很可能跟repeat_penalty和上下文长度有关，Qwen2.5对重复惩罚比较敏感，调太高反而容易让句子变别扭。系统提示和用户问题之间其实不用纠结什么特殊分隔符，关键是把指令写具体，比如直接给出一个回答示例，比说“请严格按格式”管用得多。客服场景我建议你把常见问题做成少样本示例塞进系统

chunk这块确实没有万能公式，但也不是纯玄学，关键看你检索回来是给谁用、要回答什么问题。我之前做内部文档库时发现，512配50到80的overlap在多数FAQ场景还能打，但一到技术手册就崩，因为代码和表格被切碎后embedding基本废了。后来改成先按markdown标题和段落做结构切分，再对超长段落做二次递归切分，langchain那个RecursiveCharacterTextSplitt

我也遇到过，后来把冷门工具拆成按需加载就好多了，生产别挂太多。

固定长度切chunk其实挺容易把完整段落切碎的，技术手册里一段话经常跨好几百字，256字符可能刚好把关键信息截断，检索出来自然对不上。bge-large和m3e本身都还行，但embedding模型对不同领域的语义匹配差异挺大，建议先拿几个bad case手动看看召回的段落是不是真的相关。重排序变差大概率是召回阶段就没捞到正确内容，rerank只能在你给它的候选里挑，候选本身不对就没救了。可以试试按

遇到过类似的坑，后来发现光调chunk size和overlap作用真不大。你这情况大概率是文档结构信息丢了，500字符切分会把售后政策跟产品介绍硬拆开，检索时自然匹配不到。建议先按标题层级做预处理，把每个二级或三级标题下的内容单独成chunk，再保留标题作为元数据，检索时能加权匹配。overlap设个50到100字符就够，主要为了防止句子被切断，真正影响准确度的还是chunk和语义单元的对应关系

bge-large-zh做dense召回对短query本来就不稳，试试混合召回加RRF融合，别纯靠向量。 我之前也踩过这坑，后来发现512切太大了，改256加重叠，BM25和向量各取一半结果才稳。

我觉得你这问题大概率不是embedding的锅，中文长文档用OpenAI的ada-002本身就很吃亏，换个bge或者m3e这类中文模型效果会明显不一样。chunk切分方面建议你按文档结构来，比如标题、段落、表格都单独切，别死守固定size。reranker确实值得上，尤其你这种内部文档场景，先用BM25召回top50再让bge-reranker精排，比单纯调chunk参数见效快。另外排查时可以先把

说实话你现在做Agent方向的话，PyTorch的生态优势比部署那点事重要多了，LangChain、LlamaIndex这些核心库全是PyTorch系的，踩坑资料也全。TF Serving再成熟，等你真要把动态图模型塞进去的时候，那堆graph模式报错才是真要命。而且现在ONNX Runtime和TensorRT对PyTorch的支持已经很顺了，除非你们公司明确要求TF栈，否则真没必要为了“可能用

这情况太真实了，我身边好几个同事也这样。其实不是能力退化，是你的大脑把“写代码”外包给了AI，但“设计代码”的肌肉记忆还在，只是练得少了。建议每天强制自己写半小时不带工具的纯手打代码，哪怕是从零写个util类也行，保持手感比产出更重要。另外可以试试让AI先给方案，自己再动手实现，把它当pair编程而不是代笔。

说实话你这情况太常见了，向量检索本来就不擅长精确匹配，它抓的是语义相似，像“参数在哪个文件”这种问题，关键词权重反而更直接。切块512字符对中文来说可能偏大，信息太杂导致向量平均化，试试256甚至128，或者干脆混合检索，用BM25过滤候选再让向量排序。另外bge-large-zh对长尾专有名词的区分度一般，如果文档里术语密集，效果打折很正常，别全甩锅给Chroma。 我之前也踩过这坑，后来把E

先看下文档里标题层级是不是规整，不规整的话按段落切也白搭，overlap调个100试试。 小片段召回天然吃亏，试试先把售后相关段落单独建个索引，或者用parent-child检索把父文档带回来。

说实话中兴这次确实让人眼前一亮，OEX超节点强调的协同能力比起单纯堆参数更戳我，毕竟大规模训练里通信开销往往比算力更头疼。不过你最后提的那个疑虑我也挺好奇，端侧AIOS要是跟超节点调度没做好深度联动，全栈就成各玩各的了。另外，人形机器人那块儿，现阶段能跑通demo和能稳定落地商用之间差距还挺大的，得看后续他们怎么拿实际案例说话了。

试试bge-reranker-large做二次精排，你这情况大概率是向量召回阈值没卡好，内积对中文长尾词不太友好。

遇到过一模一样的坑，BM25对一词多义是真的无能为力，因为它压根不看语境。轻量点的办法其实可以先试试图谱或词典做实体链接，把“苹果手机”这类词在索引前就改写标注，比硬搞同义词表靠谱些。但说实话，纯靠规则补丁会越打越碎，你后面要真想解决歧义，还是得上向量召回，哪怕只用个轻量的embedding模型做二三路召回再做重排序也够。另外ES的混合检索只是把两个向量强行融合，核心问题没变，别指望它自动消歧。

个人感觉问题可能出在切片粒度上，500字固定切确实容易把章节语义切断，尤其企业文档里经常有表格和标题层级。建议先按文档结构（比如标题、段落）做语义切块，再配合文档级粗筛试试看，成本比调query低多了。另外bge-reranker对长文本不太敏感，你可以试试把rerank的输入改成“query+章节标题+切片”的拼接形式，效果可能会明显一些。至于关键词飘，我自己试过用LLM把query扩写成多个子

说实话，这个问题我当初也折腾了挺久，最后发现根本不存在一个万能答案。我之前做技术文档的RAG，试过512 tokens，结果检索出来的段落经常把两个不相关的函数定义硬凑在一起，后来换成按markdown标题和代码块边界切，效果立刻好了不少，所以结构比固定长度重要得多。聊天记录的话就不一样了，我习惯按对话轮次切，每轮一个chunk，重叠控制在1-2句话，因为聊天本身语义跳跃大，固定token反而会把

这问题太真实了，我之前也踩过同样的坑。后来是给每个工具的输出做了个“压缩摘要”再塞回上下文，只保留关键字段和结论，不然真的一轮比一轮糊。另外可以试试给Agent加个“阶段性目标”提示，每调用完一个工具就提醒它原始任务是什么，亲测对防跑偏有点用。

1万条数据对8B模型来说确实偏少，而且你只用函数体做监督信号，可能让模型学成了“背题”而不是真正理解代码结构。512长度我猜问题不大，但建议先看看loss降不下去是不是因为数据里重复模式太多，试试把训练集里相似的函数去重，或者加一些带注释和调用的完整文件样本。另外target modules可以试试把q_proj和k_proj换成o_proj和gate_proj，有时候效果差异挺明显的。

本质区别，TF静态图那套对动态shape优化就是弱，PyTorch eager模式天然适合agent这种高频小图调度。 TF的tf.function每次新shape都重新trace，PyTorch的guard机制直接缓存，这差距在agent循环里就是天上地下。