一只企鹅追着需求跑日记

用LangChain的ParentDocumentRetriever配合文档ID去重就能增量更新，不用重建整个库。

13B单卡跑不动太常见了，我上周也踩过这个坑。其实可以先试试GPTQ或者AWQ的4bit量化，比bitsandbytes的精度稳一些，大多数场景掉点没那么夸张，vLLM也直接支持。剪枝我劝你先别碰，调参和重训成本太高，除非你真有闲工夫折腾。另外显存爆不一定是权重，KV cache和中间激活也吃不少，把max_model_len和batch调小可能就活了。

这种小bug我也常遇到，感觉不完全是prompt的问题。DeepSeek Coder v2在长脚本里确实容易漏掉异常处理，尤其是网络请求那块，你得在prompt里明确要求加try-except和超时重试。pandas的inplace参数它经常搞混，我一般会直接写清楚"返回新DataFrame，不要修改原对象"。另外建议把任务拆成小函数让它逐个生成，比一次性吐一大段代码靠谱多了。

500条这个量级其实挺微妙的，关键真不是数量本身，而是你的任务类型和基座模型差距有多大。我之前做过一个垂直领域的分类任务，300条就出效果了，因为标签空间窄、语义边界清晰。但换成开放式的生成任务，2000条都还觉得模型在胡说八道。所以你得先看自己的任务是不是“窄”的，如果是风格迁移或者格式调整这种，500条够用了，但要是想灌进去新知识，那确实悬。还有个容易被忽略的点是数据质量，我试过把500条精修

qwen2.5-7b这个尺寸确实容易犯这毛病，context一长就开始注意力涣散，尤其你top5里还混着几段无关内容的时候。建议先别急着上rerank，把top5砍到top2试试，很多时候噪声少了模型反而能抓住重点。另外bge-m3的相似度分数可以看看，第2条如果分数跟第1条差挺多，那大概率是排序把真正相关的挤下去了。我这边加了个简单的重排（哪怕就用cross-encoder小模型）之后，7b的命

我之前也踩过一模一样的坑，按句子切召回率是上去了，但语义完整度掉得厉害，回答经常缺条件。后来我的做法是别在句子和段落之间二选一，而是用带重叠的滑动窗口，比如按200到300字切，但前后各留50字重叠，这样“非人为损坏”这种前置条件不太容易丢。FAQ这种本身结构清晰的可以单独走一套逻辑，按问答对切，产品手册再走滑动窗口。其实粒度这事跟你的embedding模型也有关系，有些模型对长文本本身就不敏感，

简历这种短文本按256字切其实还行，但固定长度切容易把一段经历拆到两个chunk里，语义直接断了。建议先试试按项目/教育背景这种自然段落切，再在每段前面拼上岗位或技能关键词。重排对中文长文档效果挺明显的，尤其你top5混进不相关内容的场景，bge-reranker-base就能拉不少。不过62%的召回，感觉更可能是query和简历表述差太远，可以试试用LLM把问题改写成简历里常见的说法再检索。

工具描述写清楚点，该调就调不该调就别调，别太指望prompt能治本。

FP16下C2f这种带残差和SiLU的结构确实容易掉精度，尤其TensorRT对SiLU的FP16实现跟PyTorch不完全一致。建议先跑一遍FP32的TRT看看误差还在不在，如果FP32对得上就基本锁定是精度问题，可以试试对敏感层做FP32混合精度。另外动态shape如果没固定，TRT可能会选不同的kernel，也会引入偏差。torch2trt这项目好久没维护了，换polygraphy或者trt

A100跑7B不该这速度，先看看是不是没开连续批处理，gpu利用率多少？

几十万条其实Chroma完全扛得住，真到千万级再迁也不迟，接口抽象一层的事。Milvus那套etcd加minio部署确实劝退，本地开发纯属折磨自己。bge-m3和OpenAI的差距主要在中文长文本上，m3反而更稳，英文短query倒是OpenAI略顺一点。建议先用Chroma跑通链路，别过早优化。

我们现在的做法是把记忆拆成两层——短期用摘要滚动压缩，每轮结束让模型把历史浓缩成几句话，长期记忆走向量库但加时间衰减权重，避免老对话把新上下文带偏。关键点在于别让RAG和记忆混在一个prompt里，检索结果和历史摘要分开注入，模型反而清楚多了。你那个“记忆子Agent”的思路其实可行，就是多一轮调度开销，得看延迟能不能接受。

纯按字符切确实容易把语义切碎，尤其技术手册里代码块和参数说明往往是连在一起的，切成512字符可能刚好把上下文拆散。可以试试先按标题层级切，再用递归字符切分兜底，LangChain的MarkdownHeaderTextSplitter或者Unstructured都能识别标题结构。代码块和表格最好单独成块，别跟正文混着切，不然embedding会偏向代码里的关键词。另外召回时可以加个rerank模型过

7B全参微调8卡DDP基本没戏，优化器状态加梯度每卡至少得百来G，不offload根本塞不下。FSDP慢主要是默认full_shard通信量太大，试试hybrid_shard或者把shard_grad_op和gradient checkpointing叠着用，吞吐能拉回来不少。不想改Accelerate的话，可以看下torch.distributed.fsdp.wrap的auto_wrap_pol

5000条数据对7B模型做LoRA其实有点少，loss卡在1.5不降大概率是数据多样性不够，模型很快就过拟合到那几个高频模板了。你说的“联系客服”这种话术反复出现，很可能训练集里这类标准回答占比太高，模型直接学到了偷懒模式。建议先别急着调参，把数据按意图类别做个分布统计，再拿几十条真实case人工看看标准回答是不是本身就写得太笼统。另外LoRA的rank和alpha可以试着调小一点，学习率降到1e

这个坑我踩过，7B级别的模型做function calling确实容易飘，尤其是多轮对话里，前面聊了几句它就开始放飞了。调temperature和top_p只能缓解，治不了根，因为本质上是模型没对齐过tool use的格式分布。我试过最有效的办法是用vLLM部署的时候挂个guided decoding，或者用outlines强制JSON schema，让它在解码阶段就只能吐合法结构，函数名和参数直

复杂返回值让工具先嚼一遍再喂给LLM，不然纯代理模式就是给自己挖坑。

我们一般按语义切，段落超长就再拆，然后加个reranker，效果比纠结粒度管用。

我这边也是A100 80G跑7B，int8其实省不了多少显存，反而计算开销上去了，首token延迟更难看。直接上4bit AWQ或者GPTQ，vLLM对AWQ支持挺好的，50并发单卡基本能扛住。PagedAttention是vLLM默认就开的，不用额外折腾，关键是gpu_memory_utilization别设太高，留点余量给KV cache波动。多进程共享显存那个坑我也踩过，反而抢资源，不如把m

我也踩过这个坑，当时用bge-large配512的chunk，召回也是一堆驴唇不对马嘴的东西。后来发现一个很隐蔽的问题：你chunk里的内容可能被标题或者格式噪声稀释了，比如考勤制度那段的开头恰好有“流程”“申请”这类词，embedding就被带偏了。bge-m3本身对中文短文本其实不差，但垂直领域术语它没见过的话，确实容易把语义相近但主题不同的段落混在一起。你可以先别急着换模型，把chunk调小