周末知识管理学习簿

角色设定这种真不是玄学，我试过同样的问题加不加“资深工程师”输出差异挺明显的，尤其代码规范上会自觉很多。上下文我一般控制在能跑通的最小闭环，示例放两个就够，一个常规一个边界，多了反而容易让模型照着错误示例模仿。模板的话，我习惯把需求拆成“输入输出定义+约束条件+验收标准”三段，比单纯分步骤好用，你下次可以试试。

试试给记忆加个时间衰减权重，或者用GraphRAG做实体关系存储，比单纯向量召回稳很多。

我之前也踩过这个坑，500字确实太碎了，尤其技术文档里参数和错误码这种碎片化信息多，语义被切断了自然召回一堆噪声。我后来换了个思路，先按章节或标题切块，再对超大块用递归分割，同时把重叠提到100字，效果好了不少。另外你可以试试在召回后加一层rerank，比如用bge-reranker，比单纯调top-k管用。embedding模型我倒觉得不是主要瓶颈，先优化切分和重排试试。

我也遇到过这种情况，后来发现prompt写太细其实是在给模型“加戏”，它反而会去硬凑结构，忽略了内容本身的关联性。现在我就留一句“根据上下文回答，不确定就直说”，别的全靠few-shot带节奏，效果稳多了。你试试把那些约束条件拆出来放到检索前处理，比如先过滤掉低相关片段，再让模型自由发挥，可能比在prompt里反复强调更有用。另外输出格式要求我一般只给个极简模板，太具体了模型容易本末倒置。

带过几个训练集群的应该都懂，内存带宽不够时GPU算力就是个摆设。你提到良率问题很关键，16层堆叠的TSV工艺哪怕良率差1%，产能爬坡的节奏也会被拖累，这确实比单纯砸钱扩产更考验工程积累。不过我倒有点好奇，这次募资会不会优先保障自家跟英伟达绑定的供应量，毕竟现在HBM的订单排期比想象中更离谱。另外你说换HBM3后利用率能从60%拉到85%，我这边踩坑更多是卡在散热和供电设计上，不知道你们当时怎么平衡

这个差别其实挺正常的，Ollama跑本地模型默认温度啥的和OpenAI不一样，而且Qwen系列对指令格式的敏感度跟GPT不完全一样。我之前也踩过这个坑，后来发现把system提示词拆成几条更具体的约束塞进user里，漏字段的情况会好很多。你试试输出JSON的时候加个“必须返回完整字段，缺失就用null”这种强硬指令，效果会明显改善。另外本地模型如果显存不够，量化版本对格式遵循能力也有损耗，可以看看

角色设定太宽泛确实容易带偏，它更像给模型加戏，不如把预算全花在指令和示例上。

说实话，把AI当结对编程的实习生用就对了，大方向它给个草稿，细节还得自己把关。

你这情况我太熟了，光调向量和分块真不够。可以试试混合检索，用BM25或者ES的全文检索跟向量结果做个加权融合，尤其处理数字和年份这种精确匹配时效果立竿见影。另外HNSW的efConstruction对召回影响其实没那么大，更关键的是把query里的实体或者时间信息抽取出来做个硬过滤，比单纯靠相似度靠谱得多。

之前我也卡在unexpected EOF上，后来发现是MCP server压根没起来，得先手动在终端跑一遍确认能正常输出，然后再让Claude去连。另外Node v18可能有点旧，有些依赖会抽风，我换到v20之后就没再报过这错了。你检查下server启动时的stdout有没有报错，多半是缺少环境变量或者路径权限问题。

看着像是checkpoint里存的state_dict跟你模型定义对不上，重点查一下是不是之前训练时改过fc层参数或者加载了旧的预训练模型。你贴的报错里fc2.weight是64×128，但代码里应该是128×10，说明权重shape和网络结构根本不是一个版本，可能模型定义里有别的全连接层没注意到。建议直接打印model.state_dict().keys()和checkpoint里的keys对比

几百条样本对7B模型来说太少了，rerank还是得用专门训练过的cross-encoder更稳。 你这是样本量太小，LoRA没学到泛化规律，试试加大到几千条或者直接用现成的rerank模型。

合同提取这种任务真别迷信模板，Alpaca和ShareGPT本质区别不在格式而在数据形态——单轮指令用Alpaca，多轮对话用ShareGPT，混着用容易让模型混淆边界。我试过把两类数据按比例混合，结果收敛明显变慢，后来干脆分成两个LoRA训练，效果反而更稳。你如果偏重合同，建议先拿ShareGPT格式把对话轮次撑起来，再用Alpaca补单轮指令，比例控制在3:1左右。另外，模板里加不加系统提示词

显存这块确实是个坎儿，我们团队试过量化到FP8跑，效果打折不说，长上下文一上去还是容易爆。不过推理链断裂的问题改善是真的明显，之前用Qwen写个多文件项目经常要人工把上下文塞回去，GLM-4.5至少能自己扛住几轮修改，这体验差距比跑分直观多了。 另外你说“原生融合”的方向我挺看好的，但总觉得现在Agent能力还是有点偏“代码特化”，换到其他工具调用场景不知道会不会又露馅。有没有人拿它跑过那种需要

同感，few-shot在摘要上真容易带偏，试试把例子放最后并明确标注“仅供参考”。 八成是例子干扰了指令权重，可以加一句“严格基于原文”再试试。

说到这个我太有共鸣了，我们之前做内部工具也卡在同样这坎上。A10那24G跑7B其实挺尴尬的，vLLM默认配置下prefill和decode混在一起调度，10并发确实容易把显存带宽吃满，延迟直接崩。我后来试了试把max_num_seqs调小到4，再把--enable-chunked-prefill打开，体感会好很多，虽然单请求首token稍微慢点，但至少并发时不至于全军覆没。 至于FP8还是张量并

建议把大组件拆成多个小文件分别让AI写，再手动拼装，别指望它一次搞定完整业务。

这问题我太有同感了，Agent写CRUD确实溜，但一到状态机这种带时序的逻辑就露怯，本质上是它没在脑内把“所有可能路径”走一遍。我现在的土办法是，把关键分支和边界条件直接写成“伪代码+断言”塞进prompt里，让它先输出每一步的输入输出预期，再动笔写。另外别指望一次搞定，让它写个带详细日志的版本，你跑一遍把报错喂回去，比干调提示词管用。复杂业务真不能全托管，它更适合当个高级结对程序员，你盯着设计，

这个现象我踩过好多次坑，除了clip skip，还有vae和refiner切换逻辑，ComfyUI里很多节点默认行为跟WebUI不一样，比如末了那个decode阶段是否自动做hires fix。你试试把WebUI的clip skip改成1，然后关掉任何动态CFG或面部修复，再把vae文件强制指定成同一个，八成就能对上。另外ComfyUI对负向prompt的处理有时会走不同分支，建议直接对比一下两个

我之前也踩过类似的坑，查了半天发现是MCP的tool description里塞了太多示例，结果模型把示例里的关键词当成查询条件去匹配了，后来把description精简到只剩必要参数说明就正常了。超时那边建议你检查下MCP的默认timeout配置，我这边之前设了300ms，结果RAG服务那边embedding还没算完就断了，最后只能同步改成异步轮询才解决。