周末写作备忘录

几十万条1536维的向量，说实话pgvector完全能扛住，我之前有个类似规模的项目用的就是pgvector，配上HNSW索引延迟挺稳的，而且metadata过滤直接走SQL，省得你再维护一套过滤逻辑。但如果你后面向量量级要往百万甚至千万走，那还是趁早换专业的向量库，迁移成本后面会更高。Milvus单机部署确实偏重，etcd、minio一堆依赖，运维心智负担不小，不过它的索引类型和调优空间更大，延

loss降不代表模型学到了有用东西，5000条数据跑3个epoch，2e-4学习率对LoRA来说偏高了，很容易过拟合到那些套话模板上。建议先降到1e-4甚至5e-5试试，epoch也减到1-2，然后重点检查下你的数据格式，instruct模型微调时prompt模板和special token有没有对齐。还有个可能是你数据里本身就有一堆“好的我理解”这种客服客套话，模型只是学会了复读高频模式，得把这

你有没有把检索结果拼进训练样本里？不然模型肯定学成背答案了，生成时根本不看检索。

loss在0.9卡住挺常见的，先查查数据里是不是混了太多重复片段或注释噪声。

你这个“相关但不精准”的描述挺典型的，我之前做PDF手册问答也踩过类似的坑。固定500字切分对技术手册其实不太友好，尤其是配置类内容，步骤和上下文经常被拦腰截断，检索时很容易把“安装CUDA”和“配置GPU环境”混在一起，因为它们语义上本来就挨着。bge-large-zh本身不差，但它对chunk的语义完整性很敏感，碎片太多时再强的模型也拉不回来。你可以先别急着换embedding，试试按标题或段

我后来是让模型输出固定格式的JSON，里面带一个"answerable"字段，检索到的内容撑不起来就标false，比纯靠prompt让它自觉靠谱多了。另外你可以试试把问题先做一次query改写，拆成子问题逐个去检索，缺哪块它反而更容易暴露出来。阈值调高召回掉得厉害这个坑我也踩过，感觉单纯调阈值不如在rerank那层加个打分过滤。

我踩过一模一样的坑，4个工具串起来就开始鬼打墙。后来发现关键不是temperature，而是ReAct的prompt里工具描述太模糊，模型分不清“查数据库”和“计算”的边界。我改成每个工具加几个few-shot示例，明确什么时候该调用谁，稳了不少。多步任务确实别硬靠Agent自己规划，可以试试拆成固定workflow，或者上LangGraph把流程节点画出来，比纯ReAct靠谱。

固定500切块对技术手册确实容易切碎，配置步骤经常跨段被拆开，top_k调再大也救不回来。我之前也踩过这坑，换成按标题层级递归切块后召回明显好转，你可以先试试MarkdownHeaderTextSplitter那套思路。至于评估，别光靠肉眼，搞个几十条问题加标准答案的小测试集，算一下命中率就够了。embedding倒不一定背锅，bge-large在中文技术语料上一般够用，先动切块性价比更高。

7B模型在单卡上跑torch.compile确实挺容易踩坑的，graph break多半是HuggingFace模型里那些动态控制流搞的，编译不出来反而白折腾。我之前也试过，后来把mode设成"default"配合dynamic=False才稍微好点，但显存涨是必然的，它要缓存编译图和中间结果。建议先跑个profile看看瓶颈到底在不在kernel launch上，如果本来就是compute-bo

参数表被召回其实挺典型的，固定512切分很容易把表格和上下文切散，embedding抓到的可能只是零散数字。你可以试试按标题层级或语义边界来切，或者给chunk加上所属章节的标题一起embedding，召回会准不少。另外milvus里top_k别设太大，先卡到3-5看看效果。实在不行就上rerank，bge-reranker对这类噪声过滤挺管用的。

我之前也踩过这个坑，后来用文档ID加hash做版本标记，每次只对变更的chunk重新embedding，旧的按ID删掉就行。ChromaDB支持按metadata过滤删除，配合LangChain的增量索引不算太重。关键是你得在检索时带上最新版本号过滤，不然新旧向量会同时被召回。

光靠prompt里写1234，模型该跳步还是会跳，这个我踩过一模一样的坑。后来发现根子在于你把“判断意图”和“调API”放在同一次生成里，模型看到API描述就手痒，很容易直接冲过去。我的做法是把流程拆成两轮甚至多轮：第一轮只让它输出意图加置信度，拿到结果后代码里判断，再拼第二轮的prompt去调接口，这样它根本没机会跳。另外你说的“自己脑补缺失信息”也挺典型，可以在prompt里明确要求缺参数时必

本质区别还是在设计哲学上。PyTorch的Tensor更像numpy数组加了个autograd的壳，eager执行，所见即所得；TF 1.x那套是先建图再跑，Tensor只是图里的符号占位。TF2虽然也eager了，但tf.function一装饰就悄悄把Python代码trace成图，所以行为会变。转换这块你感觉对了，tensor.numpy()和tf.convert_to_tensor大概率都要

这个“Transport not ready”我之前也踩过，折腾了大半天才找到原因。MCP服务器确实得用asyncio那套来跑，官方SDK里的Server.run()内部会负责建立stdio的读写循环，如果你自己用同步的input()或者没把handler声明成async，初始化握手阶段就会直接卡死，客户端那边等不到initialize响应就报通道没就绪。还有一点容易被忽略，就是千万不能往stdo

这个感受太真实了，我去年做类似的东西也是这个心路历程。其实问题可能不全在框架，而是很多人一开始就把“让模型自己决定一切”当成了目标，结果发现模型在分支判断上的稳定性根本撑不住业务复杂度。你写硬编码规则兜底，本质上是在用确定性逻辑去补概率模型的洞，这本身没毛病，关键是补完之后系统到底还有多少比例是靠模型决策的。如果兜底代码超过一半，那确实得重新想想这个Agent的边界在哪，是不是只该让它处理那些规则

20万数据lists=100太大了，IVFFlat得按行数开方设，换HNSW试试吧。

200字符分块对代码文档来说确实太碎了，一个完整的订单创建逻辑可能横跨好几个函数和注释，切这么细很容易把语义打散。你遇到的“创建订单”召回“创建用户”，大概率是embedding在短文本上区分度不够，bge-large-zh对代码类内容的语义捕捉本来就偏弱，加上50重叠也救不回被切断的上下文。可以试试按函数或段落边界来分块，保留完整语义单元，顺便在chunk里带上API路径或模块名做上下文锚点。意

2万条日志3个epoch大概率过拟合了，试试加点参数类型错误的负样本，再做点schema约束解码。

量化加流水线并行确实能缓解，但vLLM对AWQ的支持比GPTQ稳一些，你可以先试AWQ 4bit加--max-model-len 8192。流水线并行在vLLM里其实主要是TP，单机多卡开TP=2能明显降单卡显存，不过通信开销会拉高延迟。另外检查下是不是没开--enable-prefix-caching和--gpu-memory-utilization 0.9，默认值有时候偏保守反而浪费显存。

几万条文档真没必要上Milvus，pgvector完全够用，还能少维护一个服务。并发超时大概率不是Chroma本身的问题，先看看是不是embedding那步卡住了。召回率这块，embedding模型的影响其实比索引方式大得多，索引主要决定速度和精度之间的取舍。我之前也纠结过一阵，后来发现换个好点的embedding模型，效果提升比换数据库明显多了。