企业级NLP应用札记

我也踩过这坑，模板太死反而让模型在多轮里丢了重点，试试精简few-shot再混点自然语言。

5000条数据做客服其实不算少了，loss震荡不降大概率是数据质量的问题，问答对里有没有很多重复或者矛盾的样本？另外你只改attention层rank16可能容量不太够，客服场景术语和话术差异挺大的，试试把mlp层也加上，rank拉到32看看。还有loss不降不代表模型没学到，生成不稳定可能是过拟合到训练集的固定句式了，建议留个验证集盯着eval loss，比盯train loss靠谱。

7B模型做分类确实容易这样，我试过把指令挪到system里会稳不少，user只放待分类文本。另外temperature 0.1对分类来说可能还是偏高，可以试试贪心解码或者设成0。还有个坑是max_tokens别给太大，不然它容易自由发挥。few-shot示例最好固定格式，连标点都别变。

16G跑7B的Q4按理说够用，问题多半出在KV cache上。ctx 4096加上system prompt和几轮对话，KV cache能吃好几个G，显存直接见底。可以试试把ctx降到2048，或者开flash attention，llama.cpp加-fa参数能省不少显存。另外vLLM对40系卡的支持确实容易踩坑，建议先用llama.cpp的server模式跑通再说，别急着换框架。

Agent逻辑跟推理框架关系不大，把LLM用API调就完事了，纠结这个纯属浪费时间。

3000张图微调ResNet18按理说不该这么难，loss卡1.8有点像学习率没调对，你用的多少？另外预训练模型如果没冻结底层，小数据集很容易过拟合或者震荡，可以试试先只训fc层再解冻。还有检查下数据增强是不是太狠了，或者标签有没有对错，我之前就踩过label mapping错位的坑，acc死活上不去。

负样本一定要加，不然模型分不清啥时候该调工具。2k数据也偏少，参数格式错多半是数据格式不够干净。

不建议硬套框架，先把任务拆成可验证的小步骤，每步设个退出条件试试。

固定500切块对技术手册确实容易踩坑，配置步骤经常被拦腰截断，检索出来自然缺胳膊少腿。你可以先试试按标题层级做递归切块，同时把chunk_size放大到800左右，让完整操作步骤尽量待在同一块里。评估的话别光靠眼睛，搞个几十条query-答案对，算一下recall@5和MRR，调参方向马上就清楚了。bge-large本身中文检索不差，问题大概率还是出在切块粒度上，先把这块理顺再考虑换模型。

混合检索加rerank才是正解，纯向量召回本来就容易跑偏，换个库解决不了语义匹配问题。

Qwen2.5-7B的KV cache按层数×头数×维度×长度×batch算，公式里漏了它就必OOM。延迟低直接上vLLM，TGI吞吐好但首token慢。

说实话官方至少会修漏洞，社区项目真得自己扒源码看请求日志，别怕麻烦。

时间衰减这块确实麻烦，我试过在元数据里存时间戳然后自己写个重排逻辑，但Chroma的query结果集太小的话效果也一般。短期记忆我干脆单独开个collection存最近几轮，长期记忆就定期做摘要压缩再存，不然原始消息堆多了全是噪音。你这个碎片化问题试试把对话按主题切块后再存，别一条条塞。

说实话我觉得你这大概率不是embedding的锅，bge-large-zh处理中文已经够用了，问题还是出在分块上。500字符固定切很容易把保修条款和安装步骤硬凑到一个块里，尤其产品手册这种结构化的文档，按标题或者章节去切会好很多。另外混合检索确实值得试，BM25能兜底关键词匹配，至少不会问保修政策给你返回安装步骤。你可以先拿几个失败case看看是召回就没召对，还是召对了但rerank没排好，这两条

这问题我也踩过坑，chunk大小和重叠只是表面参数，根源是业务语义边界跟字符边界不匹配。违约金这种跨章节的强关联信息，光靠向量相似度确实拉不回来，重排也只能在给定候选里挑。父子chunk算是最直接的解法，父块给足上下文，子块保证精度，预算够的话值得试。另外可以按文档结构（比如条款标题）先做语义切分，再在切分结果上套512的窗口，这样比固定长度硬切靠谱得多。

我之前也踩过这个坑，把对话全塞一个collection肯定不行。我的做法是分开建两个集合，一个存知识库，另一个专门存用户偏好和长期记忆，元数据里带上时间戳和对话id，查询时用filter限定范围。另外，短期对话直接存Redis或者SQLite做滑动窗口，只把重要的总结写入向量库，召回率会高很多。ChromaDB的话，建议给每个用户单独分collection，不然数据交叉干扰挺麻烦的。

我之前也踩过这个坑，LangChain拼出来的top3 chunk如果和问题关联度不够，模型确实容易“自由发挥”。后来我试了在system prompt里加一句“你只能使用上下文中的事实，如果信息不足，必须明确回答‘根据提供的资料无法确认’”，比在user prompt里反复强调管用得多。另外，你可以在把chunk拼进去之前，先用一个简单的重排序或者关键词过滤，把明显不相关的段落剔掉，不然模型会被

torch.compile对静态shape的CNN或者BERT那种定长任务确实有效，但生成式模型这种每步token长度都在变，inductor的图优化很容易被频繁recompile打断，反而得不偿失。我试过把beam search的padding统一到固定长度，稍微好点，但跟eager比还是没优势。vLLM和TensorRT-LLM的核心优势是paged attention和算子融合，这俩是专门为

大概率不是heartbeat的事，先查下K8s的service和ingress超时配置，默认往往很短。 之前我也栽这坑里，把存活探针和读超时调大点，顺便看下TCP keepalive。

先别急着换embedding，你这个情况大概率是召回的问题。ada-002本身对语义相似度的把握还行，但产品手册这种结构化差的PDF，直接切chunk很容易把流程步骤和参数表混在一起。我建议你先做一下文档清洗，把标题、章节层级提取出来，按章节而不是固定长度切，然后再试试用关键词+向量混合检索，比如加个BM25过滤。另外，你提到的“售后服务流程”这种query，可能本身就偏实体指向，你可以先手动跑几