长期关注创新工作台

你们每天全量重灌其实挺勤的，faiss本身倒不至于一个月就退化，除非ID映射或删除逻辑有坑。我比较怀疑是embedding模型版本或归一化方式在中途被动过，或者线上query分布跟测试集漂移了。可以先把最近的bad case捞出来，人工看下是召回不到还是排到后面去了。query改写和意图识别确实有用，但别一上来就堆模块，先确认是召回阶段的问题再动手。

产品手册这种文档光靠固定长度切分确实容易翻车，表格和参数列表被切碎后语义全乱了。建议你先别急着调chunk size，拿几个bad case看看召回的chunk到底是切歪了还是embedding压根没抓住“流程”这类词。可以试试按标题层级做结构化切分，或者用small-to-big的思路，检索用小块但喂给模型时带上父级上下文。另外确认下你query有没有做改写，直接拿“售后服务流程”去匹配，跟手册

你这个情况我太熟了，去年做合同问答踩过一模一样的坑。先说结论：你这种“具体金额”查不到的问题，八成不是embedding的锅，而是切分把关键信息切碎了。技术手册和合同条款最要命的就是表格和长句，按固定字数切很容易把“违约责任”和后面的金额拆到两个chunk里，那检索再强也白搭。你可以先别急着换模型，把PDF解析出来的文本打印几段看看，大概率会发现表格变成了一堆乱序的数字。bge-small其实对中

你这个感受我太懂了，之前我也踩过一模一样的坑。说实话，prompt工程在代码生成这块确实有用，但它的天花板比很多人想象的低，尤其是碰到复杂业务逻辑的时候。你加一堆角色设定和格式约束，模型反而可能把注意力分散到“表演”上，而不是老老实实把字段名和判空写对。我现在的做法是把大任务拆成小步骤，比如先让它只输出数据模型和字段清单，确认无误后再让它写单个函数的实现，每次只聚焦一个点。few-shot示例确实

我也遇到过这种情况，感觉是提示里任务太笼统，模型就爱偷懒写占位符。后来我把“去重、填充空值、异常值处理”拆成三个小步骤分别描述，比如去重按哪几列、空值用均值还是前向填充，它就老实把代码写全了。另外可以要求它给一个带样例数据的完整脚本，别只写函数，这样占位符基本就没了。

我也踩过这个坑，几个Agent互相转来转去，最后全靠超时兜底。后来发现光靠max_rounds不够，关键是每个Agent得有明确的"职责边界"，比如技术支持只判断是不是硬件问题，判完就输出结论走人，别让它有转回客服的权限。另外可以加个全局的意图路由，用户问题进来先分好类，而不是让Agent之间自由传递。你那个关键词+LLM打分确实太模糊了，建议把路由决策和回答生成拆成两步，会稳很多。

我也踩过这个坑，ReAct的prompt里如果没明确告诉它啥时候算完，模型就容易手痒多调一轮。可以试试在系统提示里加一句“如果已有足够信息回答用户，直接输出最终答案，不要调用工具”，效果挺明显的。另外LangGraph里可以用条件边判断最后一条消息有没有tool_calls，没有就直接走END，不用非等轮数跑满。

固定500的切法确实容易把语义切碎，尤其口语化query丢主语的时候，向量匹配基本靠词面撑着，召回飘很正常。我自己的经验是先别急着上语义切块，可以先按标题、段落、列表这种自然边界切，chunk_size也不是固定值，而是跟着结构走，overlap保留一句到两句就够。query那边做改写挺有用的，比如让模型把它补全成完整问句，或者生成两三个同义query再合并检索结果，比单纯调大top_k靠谱。表格

大概率是生成阶段没盯住上下文，模型偷懒自己发挥了。试试把prompt改成强制它只依据原文回答，答不了就说不知道。

量化加流水线并行这个组合我确实试过，但踩了个坑想提醒一下。AWQ量化对Qwen2.5支持还行，显存能压到原来一半左右，但vLLM的pipeline parallel跟tensor parallel不太一样，它主要是跨节点用的，单机多卡反而容易因为通信开销把吞吐拖下去。我当时双卡A100用PP=2，单请求延迟直接涨了快40%，后来改成TP=2才正常。你8并发就OOM挺奇怪的，80G单卡跑7B的FP1

500条样本想学一种风格确实偏少，模型很容易就过拟合到你那几条高频表达上了。loss从2.3到1.8卡住，未必是数据格式问题，更像是学习率偏小加上样本多样性不够，试试把lr拉到1e-4附近再配合cosine调度看看。另外[INST]这种标记得看基座本身有没有对应的chat template，Qwen2.5最好直接用tokenizer自带的apply_chat_template，自己手写容易和预训练

切分粒度确实值得先查一下，60-80个token的长句里可能混了好几个主题，向量被平均掉了，试试按语义切短一点，或者加个滑动窗口重叠。另外“苹果公司”和“iPhone销量”这种，关键词没重合但语义相关，召回低很正常，可以看看是不是纯向量检索在扛，加个BM25混合检索会稳很多。768维对中文短句其实够用了，BGE本身没问题，重点还是切分和检索策略。

13B加载完就30G，是不是没开半精度或者量化？我一般直接用GPTQ的4bit，精度掉得没想象中狠，日常问答几乎感觉不出来。剪枝确实麻烦，不如先试试AWQ量化，对算子支持友好一些，速度也还行。你显卡是哪张？24G的话跑13B 4bit基本够用了。

检索回来的片段可以加个相关性打分，分低的直接别塞进去，不然模型容易被带偏。

这个思路不错，收藏了。

vLLM 默认是按吞吐优化的，单请求延迟反而不占优势，尤其 Agent 这种一轮接一轮、每轮都带工具调用和历史的场景，它没法做前缀缓存复用，每次都得重算。你可以试试开 enable_prefix_caching，再把 max_num_seqs 调小、gpu_memory_utilization 拉到 0.9 左右，能压不少延迟。另外工具调用那步慢，大概率是输出 JSON 时被 stop token

你这情况太常见了，光靠向量相似度确实容易把“长得像”但没用的东西混进来。我一般会在召回后加一层重排，比如用cross-encoder或者bge-reranker对query和文档做精细打分，效果比单纯embedding好不少。另外可以试试把时间、公司名这类硬条件抽出来做元数据过滤，先砍掉明显不相关的季度和同行文档。如果预算够，混合检索加RRF融合也能缓解标题相似但内容跑偏的问题。

换模型必须重调检索，ada和BGE的向量空间根本不兼容，试试加个rerank或者直接上混合检索。

Agent该管的是检索搞不定的模糊决策，比如多跳推理或该不该查，单纯问答加rerank确实够了。

技术手册按固定字数切容易把表格和步骤拦腰断，先换语义切分试试，bge-large本身没问题。