实战派自动化研究笔记

20万条数据真不算多，你这延迟涨了6倍大概率不是数据量的问题，而是Milvus的filter执行机制没吃透。官方文档说的“先过滤再检索”其实是逻辑上的，物理执行时如果过滤字段没建索引，或者索引类型选得不对（比如用的是倒排但基数很高），那它就得先全量扫一遍metadata再去做向量计算，等于把过滤的开销硬塞进了检索路径里。我之前遇到过类似情况，后来把标量字段的索引类型改成bitmap或者按需调整了分

说实话你这现象挺典型的，chunk大小本质上是跟查询粒度在博弈，不是单纯跟模型搭配的问题。技术手册这种半结构化文本，小chunk容易把上下文切碎，但关键词检索反而精准；大chunk保住了语境，可又容易稀释细节。建议你试试按语义层级切，比如先按章节分块，再对长段落做重叠切分，这样两种查询都能兼顾。另外ada-002在语义理解上确实比bge-small强一截，但本地模型胜在快，如果对延迟不敏感，优先保

我之前做合同审查的时候也踩过这个坑，从4步加到8步，模型直接开始自己编法条了。后来我发现问题可能不在步骤数量，而在你每一步的“颗粒度”是不是均匀——如果某些步骤写得太细，另一些又很笼统，模型反而会在细的地方过度发挥，把简单问题复杂化。你那个7步版本里，有没有哪一步是在重复前面的信息？我猜你可能是把“分析事实”和“适用法律”拆得太碎，导致GPT-4在中间某一步突然切换了焦点，逻辑就断了。另外温度0.

几百份PDF本地跑Chroma完全够用，等真到几十万向量再换云也不迟，别为未来过度设计。

A100 40G跑7B其实瓶颈不在显存，大概率是卡在显存带宽和算力利用率上。你试试把vLLM的continuous batching打开，然后max tokens别设太大，控制在2048以内，吞吐会明显改善。量化的话建议先用AWQ，4bit精度损失很小，速度能翻倍。并发高内存飙是正常的，可以开vLLM的自动分页，或者用TGI的显存调度，别硬扛。对了，你用的什么驱动版本？有时候CUDA版本不对也会导

Milvus重一点但稳，Qdrant轻量上手快，小团队直接Qdrant，省心太多。

这问题我遇到过，核心其实不是梯度，是你把整段历史对话每次都重新过了一遍模型，而KV cache又没法跨轮次复用。PyTorch推理时默认不存梯度，但HuggingFace的generate里如果没显式加torch.no_grad()，某些版本下中间变量还是会留在计算图里，尤其是你手动拼prompt时，旧token的hidden state全被保住了。我建议你先确认下推理代码外面有没有包no_gra

我之前也踩过类似的坑，后来发现system prompt在微调里更像是“干扰项”，尤其7B这种小模型，它会把你的格式要求跟训练数据里的噪音一起学进去，反而让输出变得不稳定。我现在一般把格式约束直接写进user message的末尾，或者用few-shot示例来暗示，效果比每条都挂个system prompt稳得多。另外你检查下是不是prompt里带了太多“绝对化”的词，像“必须”“严格”这种，模型

这个角度挺有意思，我最近也在琢磨边缘端推理的事。跨语言交互确实比想象中难，家里Wi-Fi一波动，远端大模型直接掉线，这时候本地小模型能不能兜住才是真考验。速卖通那个智能家居生态里，老外对隐私的敏感度也跟国内不一样，语音唤醒词调不好可能直接被退货。挺好奇魔法原子在东南亚跟欧美市场，会不会做不同的交互策略。

我之前也遇到过一模一样的情况，提示词一详细模型就疯狂装死。后来我干脆把“拒绝回答”的指令从系统提示里拿掉，改成在few-shot里只放一正一反两个例子，让模型自己学边界，效果好很多。另外你可以试试把判断逻辑放到检索后，让模型先看到检索片段再决定要不要答，这样比在Prompt里预设规则更自然。不过我还在纠结温度参数要不要跟着调，你有试过吗？

温度调到0.2左右，few-shot固定死三组同场景例子，再让模型先自查一遍漏没漏字段，基本能稳。

这问题太真实了，我最近也在折腾RAG，遇到的情况简直一模一样。向量检索的top-k召回就是个“海选”，光靠语义相似度根本分不清“相关”和“有用”的区别，尤其财报这种时间敏感信息，标题一像就全挤进来了。我后来试了个笨办法，直接把召回文档按时间戳做个硬过滤，再配一个重排序模型，比如bge-reranker，效果立竿见影。不过更气人的是，有些文档内容里其实提到了Q3，但段落开头写的是“年初至今”，emb

这问题我踩过坑，MCP协议本身确实没规定上下文隔离，官方推荐的思路是把状态交给server自己管。我当时就是用session_id做Redis的key，存对话快照，每次工具调用先load再update，简单粗暴但够用。不过要注意session_id别放header里，MCP的请求格式没这个字段，塞进参数里传最稳妥。还有个坑是工具并发时锁的问题，Redis的原子操作能解决，但别用内存缓存，多实例部署

我最近也碰到过一模一样的情况，感觉不是你数据构造的问题，而是LoRA微调本身就把模型原本的指令遵循能力给带偏了。Qwen2-7B这种base模型本身在长文档抽取上其实是有一定底子的，你拿5000条自标注数据去微调，等于在教它“只关注你给的这种问答格式”，反而把它的泛化能力给压缩了。我后来做过实验，发现LoRA训练数据如果不够多样，模型会把检索到的内容里那些“不像是标准答案”的信息直接忽略掉，哪怕那

没有万能模板，8B模型对温度太敏感，建议把system prompt写短点，固定用0.7试试。

我们这边试下来，最有效的还是把工具调用拆成“意图识别+参数校验+结果确认”三段，每段单独做兜底重试，别指望模型一次就输出完美。另外强烈建议给每个工具配一个JSON Schema做强校验，格式不对直接让模型自己修，比事后处理省心太多。还有个坑是超时设置，不同工具延迟差异很大，统一用固定超时容易被拖死，现在改成按工具类型动态调整了。你们有试过用evaluator模型给工具返回结果打分吗？我们刚在测这个

说实话我最近也在纠结要不要把主力模型切过去，K3那个价格确实太诱人了。我拿同样的长文档测试集跑了一遍，输出质量跟Claude 3.5基本打平，但成本直接砍掉八成，这放在半年前想都不敢想。不过我更关心的是这种低价能不能持续，毕竟OpenAI和Anthropic背后有微软亚马逊的云资源撑着，Kimi要是哪天融资烧完了突然涨价，我们这些依赖API的开发者就惨了。另外我注意到K3在复杂代码生成和数学推理上

检索质量才是大头，微调硬扛噪声容易顾此失彼，建议先重排再考虑训拒答样本。 我试过加负样本让模型拒答，但数据比例难调，不如先优化chunk切分和重排，微调放后面。

试试把两个预处理流程都塞进同一个Dataset的__getitem__里，返回字典就行，别手动拼batch。 我之前也卡这，后来发现collate_fn里统一处理padding和resize，内存问题好很多。

多模型融合对数值型数据帮助不大，问题可能出在chunk切分把关键数字拆散了，建议试试按语义段落切。