北岸寻光

这块确实头疼，我之前也踩过坑。后来是把表格单独抽出来转成markdown再喂给模型，图表就用gpt-4o生成描述文本拼回原文，效果好了不少。不过多模态那一步延迟确实上来了，建议只对含图表的页做处理，别全量跑。另外chunk的时候可以按版面结构切，别纯按字数，不然表格必碎。

我前段时间转YOLOv5也碰到过，后来发现是SiLU的问题，torch导出时默认走的是原生实现，onnxruntime那边精度确实会掉一点。你可以试试用opset 11或者13，有些版本对SiLU的融合处理不一样。另外看看是不是fp16导出导致的，我一开始没注意这个，换成fp32后置信度就正常了。

向量分数这东西真不能太当真，余弦相似度高只说明语义方向接近，不代表内容就是你要的答案。你那个“合同违约怎么赔偿”召回一堆无关条款，大概率是嵌入模型对法律术语的区分度不够，bge-small确实偏轻量，换bge-large或者专门的法律领域微调模型会好不少。rerank我觉得挺有必要上的，尤其是top10之后精排，能把真正相关的往前顶，bge-reranker-base就够用，延迟也就多几十毫秒。向

几十万切片用chroma确实容易踩坑，它默认的HNSW参数对中文语义召回不太友好。我试过qdrant和pgvector，单人开发的话pgvector最省事，直接复用现有PG，召回也够用；真要抠延迟再考虑milvus。es向量插件召回还行但调参挺折腾，不太推荐图省事的人。

两张3090走张量并行其实是个挺尴尬的配置，卡间没有NVLink，通信全靠PCIe，TP的all-reduce开销在decode阶段会被放得很大，尤其你batch拉大之后通信量线性涨，GPU利用率卡在40%很可能就是在等通信。单请求3-4秒延迟、20 tokens/s这个数，先别急着怀疑AWQ，建议拿fp16不量化的版本跑个baseline对比一下，如果量化前后差不多，那问题基本不在量化上。AWQ

八成是vLLM默认的repetition penalty没关，本地没开这个参数吧，设成1.0试试。

动态建集合前期爽，后期连接池和tool管理绝对让你想骂人，我最后全改回单集合加payload过滤了。 Qdrant过滤性能其实够用，只要给user_id建好索引，别自己吓自己。

这问题我太有同感了，之前用7B模型做tool calling也踩过一模一样的坑。你验证集loss好看但一上真实workflow就崩，大概率不是单纯数据量的问题，而是你训练样本里压根没让模型见过“工具调用失败”或者“需要根据工具返回值再决定下一步”的场景。我后来是把真实Agent跑出来的log（包括system prompt、工具返回的JSON、模型下一步动作）直接抽出来当训练样本，而不是自己造那种

我之前也踩过这个坑，实测下来瓶颈往往不在vLLM本身，而是LangChain默认的检索和生成完全串行，建议先给Milvus的检索加个并发，或者把embedding丢到独立进程里，能快不少。另外rerank别急着上，先试试给高频query加个简单的语义缓存，命中率上来后首token能压到1秒内。你这个延迟如果是偶发性的，大概率是prompt拼接里塞了太多历史消息，把模板精简下可能立竿见影。最后想问下

我之前也纠结过这个问题，后来发现拆不拆主要还是看文档之间的语义重叠度。如果几个领域的query经常互相牵扯，拆了反而要来回做路由和上下文拼接，不如一个Agent加个文档预分类的步骤。但如果问题边界确实清晰，拆成两三个垂直Agent，各自调优prompt和检索参数，效果会明显好一截。另外你可以先单Agent跑一周，把badcase按文档类型归归类，再决定要不要拆，别一上来就上复杂度。

其实你抓到的点挺准的，MCP底层就是JSON-RPC那套，但初始化协商那步绕不开，官方SDK帮你封装了这层逻辑。我自己试过用Python的mcp库直接建个client会话，不走Agent框架，只调工具发现和调用，代码量很小，完全可行。你那个场景其实不需要管什么生命周期，只要把session建起来，拿工具列表然后call就行，别被那些Agent示例带偏了。

别纠结，现在这行情PyTorch就是事实标准，TF能部署就行，新项目全用torch写，转换的坑留给CI去踩。

直接把你的规范写进rules.md，再在Cursor里设置成全局规则，生成前就约束住风格，比手动改省心多了。

这问题太真实了，我也被坑过好几回。后来发现直接在对话里甩一句“用当前最新稳定版，别用老API”比在注释里写管用，但每次开新会话都得重复一遍。感觉模型对库版本的知识确实有滞后，尤其是那种更新快的库，它可能学的是两年前的文档。我现在习惯让它先报版本号，再贴代码，不对就让它自己查import error去修正，比手动改省点心。

说实话这俩的上下文根本没法直接换算，MCP的max_tokens管的是工具调用协议层的输出限制，跟训练时sequence length完全是两码事，你调它只会让模型输出被截断，不会省显存。工具调用返回的JSON确实会占上下文，而且LoRA前向传播的激活值才是显存大头，建议你先把微调batch size降到1试试，或者用gradient checkpointing把激活换显存。我之前试过把微调任务拆

说实话这个现象太正常了，7B模型对system prompt的“长期记忆”本来就弱，更像是个短期提示而非硬性约束。我试过把角色设定和客服规则混在few-shot里，每轮对话前都重复一遍，效果比单句指令稳不少。另外你可以试试把“不超50字”也写成示例，让模型模仿具体句式，比抽象指令管用。还有个小技巧，把system prompt里加一句“如果超出角色范围，就回复请稍后转人工”，能减少它跳回AI身份的

我们项目之前也踩过这个坑，后来是把短期记忆和长期记忆拆开的，短期用滑动窗口管最近几轮，长期靠LLM自动把关键信息抽成结构化摘要存进向量库，查询时按相关度召回。时序问题可以在摘要里加时间戳，或者用图数据库存实体关系，纯向量确实容易混。子Agent管理记忆我也试过，效果不错但成本高，小场景不太划算。你现在大概是多少轮对话开始崩？可以试试先压缩每轮内容，只保留问题和答案的核心实体，让上下文瘦身。

12G跑7B长文本确实紧巴，我试过GPTQ和AWQ，体感AWQ在长上下文下更稳一点，但峰值显存还是得靠vLLM的--enable-chunked-prefill配合开paged attention，能省不少。Flash Attention对显存优化不明显，主要是提速，别抱太大期望。另外你试试把max-num-seqs调小，比如4，能降低碎片化显存浪费，我这么搞后从4K撑到了7K左右。Streami

我们团队之前也纠结过这个，最后选了ES+向量混合，主要是权限过滤和元数据筛选太刚需了，纯向量库这块得自己折腾，后期维护成本不低。分数融合的话，我们试过简单的加权和RRF，体感RRF更稳，不太需要调参，你可以先拿小批量测试下效果。几万篇文档其实FAISS也能扛，但如果后续文档涨上去或者要动态删改，ES的运维优势就出来了。

我之前也踩过这个坑，固定token切真的容易把语义拦腰截断。后来改成按Markdown标题和列表结构先分块，再对超长块用滑动窗口二次切，召回率明显稳了。另外你可以试试用LLM给每个块生成几个模拟问题，检索时拿这些问题和用户query做匹配，比纯embedding余弦相似度准不少。切片效果评估的话，我都是手动挑20个典型问题跑一遍，看召回片段能不能覆盖答案要点，跑多了就大概知道什么文档该用什么策略了