长期关注用户研究思考录

这个真的没有万能值，我自己踩过一圈坑之后感觉还是得看文档类型和查询方式。技术文档我一般切400到600 tokens，因为它本身结构清楚，标题和段落边界明确，按markdown层级切比硬卡token数靠谱得多。聊天记录就完全不一样了，单条消息短、上下文跳跃大，我通常会把连续几轮对话合成一块，控制在300 tokens左右，再留50到80的overlap，不然一问一答被切开就废了。你说的块小信息断、

这个问题我踩过不少坑，说点实际感受。光靠把项目结构文档塞给模型基本没用，它读归读，真到改代码的时候还是盯着当前文件，因为它压根没有“调用链”这个概念，只有你给它的那点上下文窗口。我后来试过用tree-sitter先把整个仓库的函数调用关系抽出来，生成一份带层级和依赖的索引文件，每次重构前让Agent先读这个索引，再决定要动哪些文件，效果比喂文档好不少。另外Cursor的rules里可以强制它改完一

LoRA确实能缓解不少，我试过全参微调崩得厉害，换LoRA后通用能力保住了七八成，建议先试试。

7B模型输出波动大，很多时候不全是prompt的问题，batch推理开了之后同一条请求可能被padding影响，建议先试试batch_size=1对比下。固定seed在vLLM里基本没用，因为连续批处理会让采样顺序变。prompt里加格式约束确实有用，尤其是要求它先输出思考过程再给答案这种。另外可以看看是不是max_tokens设太小导致截断后重复，这个坑挺常见的。

gradient checkpointing省的是激活值，不是模型参数和优化器状态。7B模型fp16参数加Adam的动量方差，光这些就占了大头，激活那块省下来的空间相对有限，所以显存看着没降多少很正常。你这70多G里，优化器状态估计就吃掉快40G了。想再压可以试试8-bit Adam或者deepspeed的offload，比单纯调checkpointing管用。

我之前也踩过这个坑，建议先别急着微调生成器，优先把检索端搞准。专业术语召回不准的话，生成再强也是垃圾进垃圾出。可以试试用领域语料先微调bge，或者加个rerank模型，成本低见效快。生成端要训的话确实得准备带上下文的QA对，但数据构造挺费劲的，不如先把检索搞定再看效果。

我之前也遇到过类似情况，感觉不是AWQ量化的锅，FP16版本跨文件照样会飘。长上下文模型普遍存在“中间遗忘”问题，Qwen2.5也不例外，2万token后中段信息衰减挺明显的。我的土办法是把关键函数签名和类型定义抽出来，放在prompt最前面和最后面各贴一遍，中间只放当前要改的代码，命中率能高不少。

先加个rerank试试，bge-reranker对你这场景提升很明显，切分策略也可以按语义来别硬切512。

max_length 2048确实挺吃显存的，你先降到512试试，很多时候数据根本用不了那么长。另外transformers 4.31对LLaMA的LoRA支持有点坑，建议升到4.36以上，配合peft最新版会稳很多。还有个容易忽略的点：优化器状态，如果你用AdamW，7B模型光优化器就占不少，换成bitsandbytes的8bit adam能省一大截。3090跑7B LoRA batch siz

3000条数据跑一个epoch确实容易过拟合到固定话术，模型会把训练集里的回答当模板背下来，开放域反而不会答了。试试把rank降到8或16，学习率调到1e-4左右，再混一些通用指令数据进去，别让它只盯着客服语料。另外检查下是不是只训了q_proj和v_proj，target_modules太少的话效果也会打折。

24G跑7B FP16其实够了，OOM多半是没开flash attention或者context设太长，先把max_seq砍到2k试试。量化掉点很正常，但写递归都报错八成是量化校准集太烂，换个c4或者wiki的校准数据重新量化，AWQ比GPTQ稳一些。要不直接上vLLM加GPTQ-Int8，8bit基本不掉点，24G带7B绰绰有余。

chunk从512调到1024变慢挺正常的，片段越长检索时算相似度的开销越大，而且语义容易被稀释。我一般按语义边界切，300-500 token左右配个50-100的overlap，效果比较稳。检索这块可以试试BM25加向量做混合召回，再上一个轻量reranker（bge-reranker-base就够），相关性提升很明显。向量库的话Chroma小数据量确实一般，可以看看LanceDB或者Qdra

vLLM加载时默认会把gpu-memory-utilization设成0.9，24G卡直接吃掉21G多，再加上14B的权重和激活，不炸才怪。先把gpu-memory-utilization降到0.8试试，max-model-len别一上来就拉满，调到4096或8192能省不少kv cache。AWQ那7-8G是指权重占用，实际跑起来kv cache和中间激活才是大头，光看权重容易踩坑。预算紧的话建

5000条4分类其实不算特别少，但合同条款这种短文本类别边界可能很模糊，模型容易学到表面词而不是语义。loss降到1.2就卡住，更像是过拟合了训练集但泛化没跟上，建议看看验证loss曲线是不是已经开始回升。LoRA做分类任务没问题，但7B模型可能本身对这类任务就有点大材小用，试试换个思路：把分类当生成任务做，构造prompt让模型输出类别标签，效果往往比直接接分类头好。另外检查一下验证集和训练集的

这个坑我踩过，光靠prompt里写“必须按顺序”基本没用，模型该跳步还是跳步。后来我改成把意图判断单独拆成一个前置调用，先让它只输出意图标签，再拿这个结果去走后面的分支，反而稳多了。你说的“脑补缺失信息”也挺典型，我一般会在prompt里加一条：信息不全就输出固定占位符，而不是自己猜。另外可以在流程里加个校验层，比如意图字段没解析出来就直接走兜底，别让模型自由发挥。其实这不完全是prompt的问题

这俩我都踩过坑，说点实际的。几十万篇文档其实规模不算大，Milvus的“重”主要体现在你得维护etcd、MinIO、Pulsar那一套，中小团队没专职运维的话，光集群稳定性就够喝一壶的，单机版又不太敢上生产。Weaviate上手确实快，docker一条命令就跑起来了，但它内置的混合检索是BM25+向量做融合，中文分词得自己接tokenizer，默认那套对中文基本等于没有，你得在schema里配好t

工业检测那个例子太真实了，我朋友做质检也踩过类似的坑，换个批次的光照模型就懵了。感觉现在大模型在封闭场景刷分和真实物理世界的差距，根本不是靠堆数据能填上的。大佬们嘴上说加速，实际连鲁棒性这关都没过，谈什么具身智能落地。所以那个五年我觉得都算乐观，除非先把感知层的泛化问题啃下来，不然演示再酷也只是实验室玩具。

这俩不是二选一，检索决定上限，提示词决定能不能摸到上限，你改完提示词变好说明chunk_size还没卡死，但迟早得回头调。

指令放后面确实容易被上下文带偏，我后来都是先给规则再贴资料，效果稳多了。

建议按事件+实体双粒度存，对话摘要单独开一层做索引，检索时先粗后细能省不少事。清理就靠时间衰减加话题漂移检测，过期主动归档。