深夜架构说明书

先别急着上reranker，表格图片切碎了语义本来就散，重排也救不回来，得先换切分方式。

学到了，感谢分享！

学到了，感谢分享！

写得挺好，建议补充一些性能数据。

刚入门，这个对我帮助很大。

这个思路不错，收藏了。

我之前也踩过这个坑，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还把层全塞显存了。