产品进阶录

换库治标不治本，你这八成是chunk和embedding的锅，表格代码得单独抽出来处理。

200字符的chunk确实太碎了，检索出来的片段往往只有半句话，模型除了照抄也没别的办法。你可以试试把chunk放到500-800字符，再在prompt里明确要求“先理解问题再结合片段作答，片段仅作参考”。另外重排序挺关键的，用bge-reranker之类把最相关的排前面，模型对上下文顺序很敏感。

写工具脚本这类需求，prompt里最该加的是“约束条件”而不是“功能描述”。我现在习惯把输入输出格式、边界情况、异常处理都写进去，比如“路径用pathlib，不要硬编码，参数从命令行读”，这样AI就不会给你整出C盘路径写死那种事。循环变量忘记更新，往往是因为你没说清楚状态怎么变，可以补一句“每轮迭代必须显式更新xxx变量，并加日志确认”。还有个坑是AI爱自作主张加try-except然后pass掉

我们之前也踩过差不多的坑，A100跑7B量化版并发一高延迟确实顶不住，后来换成2卡张量并行才稳下来。fp8在A100上效果掉点挺正常的，客服意图识别这种任务可以试试AWQ或GPTQ，精度损失小很多。蒸馏版和原版差距主要看任务复杂度，简单分类蒸馏版够用，但多轮推理还是原版稳。你们QPS峰值大概多少？这个直接决定要不要加卡。

1亿条768维单机确实有点顶了，召回掉到1秒大概率是内存放不下全量索引，SSD再快也扛不住频繁磁盘IO。HNSW换上去大概率更吃内存，但召回能快不少，可以先把nlist调大、nprobe压小试试，别急着上GPU。真要稳的话还是得分片或者搞个内存大点的机器，单机硬扛这个量级迟早还得崩。

并发串历史基本就是状态没做隔离，我们后来直接按session_id拆开存Redis，每个请求只读自己那份。工具调用这块别让异常往上抛炸整条chain，包一层重试加超时兜底，实在不行降级成纯LLM回答。LangGraph做状态机确实比裸LangChain稳，但学习成本也得算进去，团队小的话自己维护反而更可控。

权重0.5/0.5本来就容易翻车，稠密和稀疏的分数分布根本不在一个量级，直接线性加权会让BM25那路把长文档顶上来。建议先分别做归一化再用RRF融合，比拍脑袋调权重靠谱得多。BM25对“年休假折算”这种词确实强，但长文档命中次数多会虚高，可以试试加个文档长度惩罚或者用BM25的b参数压一压。查询改写我觉得优先级更高，先把口语化问题转成制度里的标准表述，两路召回质量都会上去。

我们之前也踩过这个坑，后来发现关键不是固定切多大，而是看文本结构。技术文档按标题层级切，每段控制在300-500字带点上下文，闲聊类反而要切小点，200字左右更稳。另外可以拿一组标注好的问答对，跑一下召回率看看哪个size命中最高，比拍脑袋靠谱。

你这情况太典型了，我去年做售后机器人也踩过一模一样的坑。GPT-3.5直调最大的问题就是它没有“不知道”这个概念，你不给它明确边界，它就会顺着你的话往下编。光加“只回答确切知道的信息”其实没用，因为模型根本分不清自己知道什么，它只是觉得自己在生成合理文本。我的经验是别把知识库硬塞进prompt，塞多了反而干扰，正确做法是先做一层检索，把用户问题相关的库存或政策片段捞出来，再作为上下文喂进去，pro

我一般会把样例数据直接贴进去，哪怕就三四行，再写清楚输出要什么格式，比如列名、是否保留原索引。多步骤任务最好拆成两三次问，先让它确认读文件和列名，再让它合并去重，最后补错误处理。提示词里加一句“只用pandas，不要用其他库”也能少很多幺蛾子。

ChromaDB本地跑确实就这样，数据量大了就顶不住。我之前换了Qdrant用MCP接，持久化不用每次重load，你可以试试。

切块太碎会丢上下文，试试按段落切再加点重叠，Python多线程和环境安装混一起多半是切块问题。

之前跑别的模型碰到过类似情况，最后查出来是数据里几条超长样本的某些token在4bit下量化误差被放大，导致activation突然爆炸。你可以先试着把序列长度砍到256跑几十步看看还崩不崩，或者用fp16跑一小段对比下，能快速定位是不是量化的问题。另外qlora的scale参数确实值得查一下，特别是如果用了新版本transformers，默认值可能有变化，手动设成16或者32试试。

这问题我太有同感了，之前做合同审核也掉进过这坑。你换小chunk反而变差，八成不是embedding的锅，而是文字和表格混排时，语义被切碎了。个人经验是先用规则把表格和代码块单独抽出来，给它们打上类型标签，再对剩余正文做分层分块，比如标题层级优先于固定字数。召回阶段别急着上colbert，先加个粗排过滤，比如用bm25把包含“销售”“下滑”这类强关键词的段落拽回来，再跟向量结果做融合，效果立竿见影

变更清单这招我试过，确实比自然语言稳，但得写得像diff描述那么细才行。 建议直接把改动点列成编号清单，外加一句“禁止改动未提及代码”，能省不少事。

显存门槛确实劝退小团队，不过推理连贯性提升是真的，等个量化版再入坑。

试试把KV cache量化打开，再用llama.cpp的--no-mmap参数，OOM能缓解不少。

这个问题我太有共鸣了，固定字数切分遇到表格和代码块简直是灾难，我试过用结构感知切分，就是先按markdown标题或者HTML的dom节点分块，再对特别长的块做二次拆分，这样能保住表格的完整性。但你说的MCP工具链里没有现成策略确实尴尬，我目前是自己在MCP server外面套了一层预处理，把文档转成统一的json结构再灌向量库，虽然麻烦但检索时能把“配置项”和它所属的段落关联起来。另外关于重叠窗口

我之前也卡在这上面，24G跑7B全参微调纯属折磨，你换LoRA方向是对的，但batch size4爆掉大概率是序列长度和attention缓存吃满了，试试把max length砍到512，客服对话一般用不了那么长。gradient checkpointing和混合精度你开了，但可以再检查下是不是忘了关gradient accumulation的同步开销，batch size1加accumulati

这种精度掉法大概率不是算子不支持，ResNet-50那几个层ONNX支持都挺成熟了。你试试导出前把模型设成eval模式，然后核对下预处理和后处理是不是跟PyTorch里完全一致，有时候是输入归一化参数没对齐。另外opsert_version可以拉到13以上，顺便检查下onnxruntime的优化级别，默认开全量优化有时候会改图结构。移动端的话4个点确实有点肉疼，但量化后可能更离谱，建议先拿校准集做