小宋Lab手记

我之前也踩过这个坑，中文不像英文按空格就能切得比较干净，递归分割器默认按标点和换行来，遇到法律条款这种引号书名号就容易崩。后来我把separators改成按句号、分号、问号、感叹号优先切，再把顿号和逗号放后面，至少能保住完整句子，但长段落还是会被拦腰截断。你提到overlap治标不治本，我特别同意，那玩意儿只是让碎块之间有缓冲，实际上语义断裂还是存在，检索时向量相似度照样被带偏。我试过按段落先切一

试试把硬规则直接塞进few-shot示例里，比写一大段背景说明管用，我这么干之后丢约束的情况少多了。

几百条数据配1e-4的学习率确实容易让LoRA记住模板，尤其客服问答这种格式高度统一的场景，r=8已经不小了。建议先把alpha降到8或者干脆等于r，学习率砍到2e-5以下试试，然后只训1个epoch看看效果。另外检查下是不是把system prompt或角色设定也当成普通文本一起微调了，这很容易让模型输出变得僵化。我之前也踩过类似的坑，后来在数据里混入一些通用指令做平衡，情况会好很多。

问题多半在特征本身，ResNet50提的512维没经过特别训练，直接拿来检索肯定不靠谱，建议换层输出或微调下模型。 试试对特征做PCA降维加白化，再归一化，Milvus那边参数反而不用太折腾。

这问题太真实了，光靠system prompt确实治标不治本。我试过把业务文档塞进知识库，结果它把需求描述也当代码规范来较真，反而更乱。后来我干脆给Agent加了条硬规则：只报能给出具体重构方案的“纯技术问题”，涉及历史背景和兼容性的逻辑一律跳过，宁可漏报也不要误报。另外你试试在PR描述里强制作者自己标注“业务妥协点”，让Agent只审查没标注的部分，效果会好很多。

混合检索值得试，BM25对人事制度这种术语匹配挺友好，能兜住向量漏掉的精确词。另外query改写别小看，“年假怎么休”改写成“年假申请条件+天数规定”再检索，命中率会高不少。你chunk_size调了但有没有考虑过把制度条文按条款粒度切？之前我做类似场景，把“休假”“考勤”这类强分类标签直接作为metadata过滤，比单靠相关性排序干净多了。

几万条数据直接上BGE吧，后面扩到几十万再换模型迁移成本更高，M3E省那点显存真不够折腾的。

我之前也卡在这过，unexpected EOF大概率不是Node版本的事，v18完全够用。你试试先手动在终端跑一下MCP server，看能不能正常启动，排除配置问题。另外检查下config里command和args有没有写对，特别是Windows下路径用双反斜杠或者正斜杠，我之前就是路径分隔符坑了自己。连不上时看看Claude的日志，有时候是它没等到server启动就超时了，可以试试调长超时时间

我之前也踩过类似的坑，训练时带系统提示词推理时去掉，效果确实会飘。但完全保留又容易让模型过度执着于那几个词，我后来是把提示词改短一点，比如精简成“你是客服”，推理时也带上，重复问题好了很多。 另外建议你看看LLaMA-Factory的文档，里面提到过训练和推理时格式一致性对稳定性的影响，不一定要一模一样，但角色设定那块最好保持同一种风格。 还有个思路是分开处理，微调时把系统提示词当作独立轮次，

推理阶段OOM基本跟LoRA训练配置关系不大，你加载模型就吃掉25G，那40G卡跑7B其实挺吃紧的，尤其如果max length设到2k以上，KV cache会占掉一大块。int8理论上能压到15G左右，但你没说用没用bitsandbytes，如果只是转成int8但加载方式不对，显存照样下不来。vLLM确实能省不少，但7B本身推理也要10G+，建议先查一下推理时的batch size和max_ne

老实说你这配置跑7B LoRA确实有点紧，但24G不该这么惨。试试把batch size压到1，同时开gradient accumulation到8，效果等同batch size 8，loss会稳很多。另外强烈建议上QLoRA，用bitsandbytes的4bit NF4量化，显存直接砍半，我记得装个peft库改几行配置就行。还有个野路子：把tokenizer的padding策略改成左侧填充，能减

我之前也卡在这上面好久，后来发现把任务拆成“步骤+格式”会稳很多，比如明确告诉模型“先列出模块清单，再逐条写影响范围”，比光说“按模块分组”管用。还有个坑是别让模型自己猜颗粒度，你给个示例输出结构，它往往就不跑偏了。你试过在prompt里加“如果信息不足，就明确说不知道”吗？这招对防止胡编挺有效。 --- 结构化这玩意儿确实玄学，我现在的土办法是写完prompt自己先当一回模型，顺着字面意思推

500字确实过载了，我一般把关键约束压到200字内，效果反而稳。 试试把few-shot砍到2个，格式用最简模板，模型自由度太高容易放飞。

这个loss卡在0.8其实挺典型的，LoRA微调代码补全时rank=8可能容量不够，尤其函数体这种结构化强的数据，试试把rank提到16或32，alpha跟着翻倍。另外你切“缺失行”的方式，如果上下文边界切得不准，模型根本学不到对齐关系，BLEU低也正常。我建议先拿1000条数据过拟合一下，如果loss能降下去说明数据没问题，否则就是格式或预处理有坑。还有，GitHub爬的代码重复度很高，去重没做

其实模型挺“认生”的，微调时见过啥格式，推理时用别的格式它就容易懵。我之前也踩过这坑，后来干脆把训练数据里混了三种模板，效果明显稳多了。不过也别太极端，模板太多可能让模型学得更慢，建议先固定两三种主流的，够用就行。另外你直接输问题效果差，也可能是因为模型没被引导出“客服”角色，可以试试点前缀提示，比如“你是一个客服”。

这现象太典型了，尤其Qwen系对system prompt的权重比想象中高，几个字的变化可能直接扰动它的隐空间先验分布。我试过把temperature降到0.5会稳一些，但偶尔也会抽风，感觉跟采样参数关系不大，更像模型本身对指令边界敏感。你可以试试把“严谨”这类抽象词换成具体行为描述，比如“回答需包含步骤和结论”，效果可能比调参数立竿见影。

试过按语义切分配递归字符分割器，长文档先分层再定长兜底，召回率能稳不少。

说实话我当初也卡在这一步好久，最后选了PyTorch，主要因为它的动态图机制在调试MCP这种多模态融合时太直观了，你可以随时print中间层的输出，断点打进去直接看张量怎么变的，TensorFlow的静态图虽然现在也有eager mode但总感觉隔了一层。不过你要是想快速验证想法、而且对底层原理还没那么熟，Keras的Sequential和Functional API确实能让你少写很多模板代码，尤

结构切分比固定长度靠谱得多，尤其你这种混合文档，先按标题拆再递归降级，overlap 10%-20%就够。想省事直接上语义切分器，topk先给10，rerank后基本能救回来。

说实话3090跑8B还得看你的max sequence length，kv cache是跟这个挂钩的。我实测vLLM在24G下，max_len设4096、batch size到4没问题，但TGI的显存控制略好一点，能到5-6，不过吞吐量vLLM更高。int4量化建议用AWQ，对话摘要影响不大，长文本确实会偶尔出现重复或逻辑跳跃，但你要是不追求极致效果完全能接受。另外可以试试把max_model_l