小周_Open手记

这个问题我也踩过，光靠System Prompt写“只回答相关问题”基本没用，模型该跑偏还是跑偏。我的经验是得加一层输出前的校验，比如让它先判断用户意图属于哪个类目，不在范围内就直接走兜底话术，而不是让主模型自由发挥。另外推荐会员卡这种大概率是你Prompt里留了“可主动推荐”的模糊空间，Agent会自己脑补。决策树确实有用，但更实际的是把边界写成硬规则加few-shot反例，光靠一句约束太软了。

我也踩过这坑，MCP的prompt只是建议，工具顺序还得靠客户端编排硬控。

相似度阈值加时间衰减就能解决，新向量先跟库里比一下，太像就别存了。

这个问题其实挺典型的，我们之前做多轮知识库Agent时也踩过。后来比较有效的做法是把检索和生成拆开，检索阶段多召回一些，比如top_k拉到20，然后用一个轻量rerank模型精排到5-8条，再进prompt。但关键不在这儿，关键是别把所有chunk原封不动塞进去，每个chunk先做一次query-aware的压缩，只保留和当前问题相关的句子，这样能砍掉一大半token。另外多轮追问时，历史对话别全

用Trae 2.0写了两周Go和Python，端侧补全确实快，敲个函数名基本秒出，但复杂重构还是得靠云端，偶尔会卡一下。CodeBuddy的多Agent我试了跨文件改接口，比想象中稳，就是资源占用有点猛，老笔记本扛不住。其实国产工具现在最实用的反而是中文注释生成和阿里云SDK补全，这块Copilot真比不了。不过两家都还在迭代，我准备再观望一阵，看谁先把计费模式和团队协作做明白。

max_num_seqs开太大反而拖慢，试试降到64，再开chunked prefill看看。

大概率是某个batch里出现了全黑的mask或者空标签，PyTorch那边算dice loss或者cross entropy时除零直接给你爆NaN了。你可以试试在loss计算前加个clamp_min把分母兜住，或者在数据加载时把异常样本过滤掉。另外PyTorch的amp混合精度有时候也会在前期偷偷给你埋雷，关掉试试看还炸不炸。

增删改这种活儿千万别让它自由发挥，我一般是把要改的函数单独贴出来，明确说只重写这一段，其他部分原样返回。另外每轮改完让它输出完整文件而不是diff，不然它很容易漏掉上下文。还有个土办法，重要逻辑自己先注释好边界，它就不太敢乱动别的了。

项目根目录加个.cursorrules文件，把技术栈和禁用写法写清楚，比prompt里反复强调管用多了。

SGLang那个OOM我也踩过，mem-fraction-static调低一点会稳不少，但吞吐确实会掉。你试过把max-running-requests压到16以内吗？A100跑32B AWQ本来就紧巴巴的，prefill和decode抢显存很难完全避免。vLLM首token飙3秒多可能是调度器在等batch凑满，加个--enforce-eager或者调小max-num-seqs试试，不过eage

验证阶段OOM大概率不是数据预处理的问题，而是你加载了带optimizer状态的完整checkpoint。optimizer的动量buffer会额外占一大块显存，验证时根本用不上，建议只保存和加载model.state_dict()。另外no_grad没配eval()确实会让BN层继续累积统计量，虽然不一定直接爆显存，但验证结果会不对。可以先用torch.cuda.memory_summary()

新手直接PyTorch吧，调试直观社区也活跃，踩坑少一半。

loss降到1.0附近就卡住其实挺常见的，不一定全是学习率的问题。你rank=8配alpha=16这个比例是OK的，但2e-4对LoRA来说确实偏大了一点，尤其是7B模型，我一般从1e-4甚至5e-5起试，不过你说降到1e-4反而升了，那大概率不是学习率的主因。更值得怀疑的是target_modules，如果你只加了q和v，可以试试把k、o还有MLP层的gate/up/down都带上，代码任务对F

我直接把指标异步丢队列，训练循环只写不读，MCP那边独立消费，基本没开销。

我本地跑Qwen2.5-Coder-7B也遇到过类似情况，写长函数到一半就停，特别是带pandas操作的时候。后来发现跟量化关系不大，换Q5和Q8都断，主要还是7B在长上下文规划上确实弱一些。我的土办法是别让它一口气写完，直接说“先写导入和读文件部分”，出来后再贴回去让它接着写下一步，反而稳很多。另外temperature调低到0.2左右也有帮助，你可以试试。

医疗问答这种任务，loss卡在1.4不动、验证集还反弹，八成是数据层面的问题，不一定是模型容量不够。7B做LoRA微调一般够用，但1.2万条里如果长短答案混杂、同一问题的回答风格差异大，模型很容易学到模棱两可的分布，loss自然降不下去。你可以先抽20条训练样本手动过一遍，看看答案质量是否真的对齐；另外alpaca模板对医疗场景确实偏简单，试试把system prompt写清楚角色和输出格式。还有

我之前也遇到过类似情况，后来发现问题不一定在chunk大小或embedding，而是bge-large-zh对短query的语义理解本身就不够细。你试试把用户问题先做一次意图改写，或者直接用hybrid检索（BM25+向量）看看能不能拉回关键词匹配的片段，毕竟faiss纯向量容易跑偏。另外400字对制度类文档可能还是有点长，我后来切成200字不带重叠，配合rerank模型才稳下来，你可以先加个re

我之前也卡在这块挺久的，后来发现chunk大小其实得跟着文档结构走，比如技术手册按章节切比硬按字数切靠谱得多。你说的“怎么配置SSL证书”返回安装步骤，大概率是chunk里混了太多上下文，试试用带重叠的滑动窗口切，或者把标题层级信息拼进chunk里当元数据过滤。embedding模型的话，bge-m3对中文长文档其实不差，但别忽略混合检索——用BM25召回top50再让embedding重排，比单

说实话，从技术迭代看T90确实比上一代聪明不少，至少从“错题记录仪”进化到能对话式诊断了。但我跟你担心的一样，如果自适应推荐的底层逻辑还是围绕考试提分转，那孩子的发散性提问很可能被算法悄悄过滤掉。我倒是更期待它能记录那些“偏离考纲”的奇思妙想，哪怕只是存档，也算没白瞎大模型的语义理解能力。 另外，动态诊断听起来很美好，可实际用起来会不会变成另一种形式的题海战术？毕竟系统越精准，推题频率可能越高，

您说的这个能力单元抽象太对了，我们之前对接后端光是清洗数据就累得半死。 这玩意要是真能落地，品牌方IT部门估计得集体转岗了。