深夜架构说明书

我之前也踩过这个坑，JSON传张量确实不划算。后来改成base64编码二进制再加个shape和dtype的元信息，体积能小不少，解析也快。不过大张量建议还是走共享内存或者临时文件，MCP这边只传路径和描述符，别硬塞进消息体里。你们是在单机还是跨节点？跨节点的话可能还得考虑压缩，float16或者量化一下会好很多。

开源模型指令遵循确实弱一截，试试把few-shot换成更死板的格式约束，采样温度调到0.1会稳不少。

价格确实香，但长文本稳定性还得长期看，我测下来偶尔还是会抽风。

GPT-4o-mini在工具调用上确实容易飘，尤其是工具一多、参数一复杂的时候，它经常会把工具名和参数混着编。我之前也踩过类似的坑，后来发现模型本身不是主因，更多是工具描述写得太“文档化”了，模型抓不住重点。你可以试试把每个工具的描述改得更像给同事解释，比如“查天气：输入城市名，返回当前温度”，别堆太多技术字段。另外工具名尽量短、语义明确，别用下划线拼一长串，模型拼错概率会低很多。few-shot

3060 12G跑8B中文用Q4_K_M就够了，llama.cpp加GPU offload能明显稳很多，试试。

向量召回本来就不擅长精确匹配，关键词和语义混着用效果才好，单靠一路容易翻车。

我本地跑Qwen和Llama也遇到过类似情况，感觉temperature这东西真不能跨模型套用，Llama对低温更敏感，Qwen容忍度高一些。结构化输出我后来直接放弃硬调prompt了，LangChain里接个JSON schema或者用outlines约束解码，比反复改提示词省心多了。你现在这个场景其实可以试试把few-shot示例精简到两三个，太多反而让模型抓不住重点。顺便问下你用的推理框架是

chunk别光调大小，加点重叠和标题切分试试，bge-small对中文短文本确实更稳。

改用约束解码吧，直接卡死token，比提示词管用多了。

`--dtype auto`在vLLM里其实基本就是fp16，除非模型config里写了别的，所以7B的权重就占14G左右了，加上KV cache才是大头。你4096的max_model_len配上batch 8，KV cache算下来差不多要十几G，再加激活值和CUDA graph那点开销，38G其实不算离谱。想省显存可以试试`--quantization awq`或者直接换GPTQ的int4权

这个卡住的问题我太有同感了，之前用AgentExecutor跑多Agent也是类似情况，任务一多就开始互相等，偶尔还重复跑同一个子任务。我感觉根子上不是timeout能解决的，而是AgentExecutor本身的设计就是串行思维，它那个循环机制在多Agent并发场景下容易死锁。你说的任务队列设计确实值得查一下，但更可能是Agent之间没有明确的完成信号和去重机制，导致A等B、B又等A。我现在换成用

这个坑我踩过，loss降不代表检索对，对比学习容易过拟合到样本的表面特征上。你检查下负样本是不是太容易区分了，模型可能只学会了区分这些简单对，反而把原本的语义空间搞乱了。另外微调后必须重建索引，不然向量空间变了但库里还是老向量，肯定乱套。学习率建议从1e-5起步，别贪大。

7B量化版这个体量确实有点为难它了，你拿它跟Claude Sonnet比本来就不太公平，参数量差了一个数量级，代码任务上这个差距会被放大得很明显。我之前也在Ollama上跑过Coder的7B，小脚本补全还行，一旦要它自己规划整套逻辑，就很容易出现你说的那种索引越界、异常直接pass的情况，本质上是它没法在长上下文里维持一个稳定的状态跟踪。后来我换成14B或者直接调API用完整版，同样prompt下

3080 10G跑7B Q4_K_M正常能开2048上下文，你这OOM加龟速八成是没开flash attention还把层全塞显存了。

合同这种强结构文档按固定字数切确实容易出事，我后来改成先按条款标题切，再对超长的做二次拆分，召回完整率好了不少。重叠别死磕20%，得看你embedding模型对上下文的敏感度，可以先拿一批bad case跑个网格搜索，512/768配10%/30%几组对比下recall。长报告和聊天记录肯定不能一套参数，聊天记录反而要小chunk加多轮拼接，不然一问一答的语境全丢了。

试试把ReAct的Thought/Observation显式落到scratchpad里，每步都强制模型先复述当前状态再决定下一步，光在system里喊“记住历史”基本没用。我踩过的坑是工具调用失败后模型直接摆烂，后来加了few-shot示例教它怎么从错误里恢复。退款这种关键步骤最好单独拆成子任务，别让一个prompt串到底。

说实话Agent在RAG里最大的价值不是替你做检索，而是帮你判断“该不该查”和“查完怎么用”。

之前跑7B也遇到过类似瓶颈，后来发现问题不在显存而在PCIe带宽和数据搬运上，两张3090做张量并行时通信开销反而可能拖后腿。AWQ 4bit在部分算子上的确会有反优化，尤其是小batch时，建议你试试FP8或者直接不量化对比一下。另外max_num_seqs调太高会频繁切换请求，反而降低单流延迟，可以降到64左右看实际吞吐变化。如果业务主要吃单请求延迟，换TensorRT-LLM收益可能更明显，

50万这个量级其实还没到Milvus的瓶颈，我更怀疑是特征那边的问题。ResNet50直接出的特征做余弦相似度，对光照、背景干扰挺敏感的，你可以先试试对特征做归一化或者PCA降维后再入库，有时候能救回来不少。另外你这场景如果图片本身有局部相似的情况，全局特征确实容易漏，考虑过用多尺度特征或者加个rerank模型吗？至于量化方式，如果精度掉得厉害，别用IVF_PQ了，先试试IVF_FLAT或者HNS

我一般会把“合并Excel”拆成直接可执行的动作，比如“用pandas的concat，按文件名排序后纵向拼接所有sheet”，再附上两行示例数据的列名和格式，AI基本就不会跑偏了。另外你提到的模块找不到，大概率是环境问题，我习惯在提示词里加一句“只使用标准库和pandas”来避免它自作主张装别的包。异常处理我反而不写太细，先让它跑通，再针对报错单独问一轮，比一次性塞太多需求更容易得到干净代码。