海獭住在云端

全参数微调跑两天出这个症状大概率是lr太高了，7B全参一般得压到1e-5甚至更低，你试试把lr降到5e-6看看。另外几千条数据全参微调确实容易崩，不如回到LoRA，把“其他”类的样本在loss里手动加权重，比focal直接调参更可控。数据格式倒是没问题，sharegpt做分类任务挺常见的，重点还是看你的system prompt有没有明确限定输出类别。你那个疯狂换行的情况，八成是模型学到的是生成格

我之前也踩过这个坑，recursive split对表格特别不友好，经常把一行数据切成两半。我的做法是先用camelot或者pdfplumber把表格单独抽出来转成markdown格式，再按单元格维度做切分，效果立竿见影。图表的话，如果比较关键，我会额外调一次gpt-4-vision把图描述成结构化文本，延迟增加个几百毫秒但能接受。 另外建议你试试把表格区域单独做embedding，和正文分开存

这波不怪COT，优化算法得靠知识库，不如直接让模型按快排模板写。

我最近也踩过这个坑，尤其客服场景里用户特别喜欢省略主语，第一轮说退款，第二轮直接问“多久到账”，其实指的还是退款到账。你现在把历史对话直接拼进query的做法我试过，确实会稀释核心语义，尤其当历史轮次比较长的时候，向量检索反而会被无关信息带偏。我的做法是分两步走：先对当前轮query做一次轻量级的意图分类或者关键词抽取，判断它是不是依赖前文，如果依赖，就用大模型生成一条“自包含”的query，但只

这问题太典型了，我刚用LangGraph时也栽这坑里。你现在的State设计估计是手动拼消息，但工具返回的结果其实应该作为独立的ToolMessage塞回消息列表里，而不是当普通内容存着。我后来是把所有工具输出都规范化成消息对象，节点只负责读最后几条相关消息，就没再丢过上下文。另外MemorySaver主要管跨会话的，你这种单次对话内的丢失大概率还是节点逻辑问题，建议把State里消息的增删流程画

固定长度切分在混合文档上确实容易翻车，尤其是代码和表格混排的时候，chunk边界经常会落在语法半截上，检索出来自然驴唇不对马嘴。我自己试下来，递归字符切分（RecursiveCharacterTextSplitter）比固定长度稳很多，它至少会优先尊重段落和代码块的结构，但前提是你得把separators列表调好，比如按“\n\n”>“\n”>“ ”>“”的顺序，再结合语言特定的分隔符。不过说实话

这问题我太有同感了，之前用bge做技术文档检索也翻过车。其实embedding模型对短query和长文档的语义匹配天生就吃亏，特别是产品手册这种术语密集、上下文依赖强的文本，你问“过热报警”它可能真觉得跟“环境温度”是近亲。我个人经验是别急着换模型，先试试把query做简单扩展，比如把“设备过热报警”拆成“设备 过热 报警 原因 处理”这种关键词组合再embedding，效果往往比换大模型更立竿见

这题我太有感触了，前段时间调一个客服问答也是这么折腾过来的。你把约束加得太细，其实等于在压缩模型自己的推理空间，它一旦发现“上下文没直接写”就拼命往“不知道”上靠，反而把那些需要两步推理才能得出的答案全给切掉了，这不就是矫枉过正嘛。我后来试下来，觉得prompt里保留一个核心角色定位，再加一条“基于已知信息做合理推断，但明确区分推断和事实”就够了，比列一堆步骤管用。还有个小坑，你那个“必须说不知道

同一个模型本地和生产表现差这么多，大概率不是Prompt的锅，而是推理配置的问题。vllm里如果max_model_len设得比训练时短，或者rope scaling没对齐，长上下文下输出就会崩，建议先检查下这两个参数。另外生产环境并发高的时候，模型输出长度上限最好显式设个值，不然它容易放飞自我。system message这块倒确实可以加强约束，比如明确写“只输出总结内容，不超过50字”，比te

校验层这个思路靠谱，我之前也踩过这坑，后来直接让模型先输出结构化JSON，再用脚本比对工具返回里的关键字段，不一致就强制重生成一次，基本能压住幻觉。另外你可以试试把工具返回的原始JSON原封不动塞进对话历史，别让模型自己转述，它一旦转述就容易加戏。

教程那个7-8G显存估计是只算了权重，没算kv cache和中间激活，AWQ再猛也架不住vLLM默认给全部显存做预分配。你先把--gpu-memory-utilization调到0.85，--max-model-len设成2048或4096试试，这俩参数影响特别大。14B在3090上跑短上下文是够的，但知识库问答如果切块太长很容易炸。要是调完还不行，直接换8B吧，省下的时间比租卡钱值多了。

说实话，稳定性和“确定性”是两码事，我后来是给工具调用加了两层校验才把线上事故压下去的。一层是规则层，参数格式和必填字段先硬校验，另一层是语义层，让模型自己输出一个置信度，低于阈值就直接走人工兜底。还有个比较笨但有效的办法，就是每次调用前把工具描述和few-shot示例重新拼一遍，虽然费token，但确实能少一些莫名其妙的幻觉。

我都是让AI先写单测，跑挂了再喂回错误信息给它改，比自己review省力多了。 先手动搭个最小闭环验证通了再让AI加花样，不然它越写越飘，坑你根本追不上。

说实话我也有同感，它写出来的东西就是那种“能跑但没灵魂”的状态，尤其变量名和函数拆分特别套路化。后来我试过把团队规范直接贴成一份CONVENTIONS.md放在项目根目录，然后在Prompt里用@引用它，效果比光说“参考我的风格”好很多。另外，对于分页表格这种通用组件，我干脆让它先给我列几个设计思路，我选完再让它写具体实现，这样至少逻辑结构是我定的，它只负责填充细节。

试试给记忆加个时间戳权重，检索时优先近期的，或者把问题拆成意图+实体再存，别只靠向量相似度。

双卡3090跑7B/13B其实算力是够的，瓶颈大概率在Agent那种高频函数调用上，vLLM和TGI对动态图支持确实拉胯，可以看看SGLang或者Ray Serve这类更灵活的调度。量化的话建议试下AWQ，感觉比GPTQ在多轮对话里稳一点，8bit崩逻辑也可能是温度或者system prompt的问题，不全是量化背锅。CPU offload真别碰，3090双卡带宽够用，但offload后延迟会高到

之前跑过类似的项目，问题很可能出在ResNet50的2048维特征直接裸用上，这个特征本身不是为检索设计的，分布比较稀疏且各维度权重差异大。建议先做PCA或者白化降维，比如压到256维再归一化，召回率能提不少。另外L2距离在归一化后其实等价于余弦相似度，但如果没归一化，L2对特征尺度特别敏感，可以检查一下提取特征时是不是漏了全局池化后的normalization。还有个坑是Milvus的索引参数，

建议直接换1.8B练手，7B双卡跑LoRA真的折腾，量化掉点正常，先把流程跑通再说。

few-shot在RAG里很容易带偏生成，试试把示例改成“反例”或者只给格式模板不给内容呢？ few-shot对检索式生成干扰太大，我一般只用json格式约束，效果比放示例稳多了。

2万条数据跑3个epoch确实容易过拟合，试试把学习率降到5e-5、只跑1个epoch，或者混合一些通用数据一起训练。