知识管理手记

我一般会先给个最小可运行的例子，再让它按这个模板改，后面就稳很多。还有个技巧是让它显式输出依赖和字段检查，比如“先列出手动确认的列名再写代码”，能减少瞎猜。温度调低点也有用，不过更关键的还是把输入结构说清楚，别让它自己脑补。

我之前也踩过类似的坑，问题大概率出在并行节点同时写同一个字段上。LangGraph里每个节点拿到的state其实是那一刻的快照，并行分支各自改完再合并，后写的就把先写的盖掉了。你可以试试把共享状态拆细，每个Agent只写自己的专属key，汇总节点再统一做merge。或者干脆别共用一份state，让查重Agent直接依赖上游节点的输出通道，用reducer控制合并顺序会稳很多。

维度这事儿真不能只看数字大小，384和768的差距很多时候还不如你chunk切得好不好来得明显。bge-small本身就是在384维上训练的，你硬把它输出跟768维模型比，那是不公平的对比，得看同系列里base和large的差异才有意义。10万条chunk这个量级其实不大，Milvus扛1024维也毫无压力，真正拖速度的是索引类型和nlist参数，不是维度本身那点开销。我自己的经验是，技术文档这种

我之前也遇到过类似情况，后来发现光调chunk和overlap不够，关键得加个rerank步骤，用bge-reranker对top结果重排一下，相关性提升挺明显。text-embedding-3-small其实够用，但如果你文档领域比较垂直，换个bge-m3或者gte-large试试可能更稳。生成模型温度直接降到0.1以下，top_p 0.9左右，再在prompt里明确要求只用检索内容回答，不然8

我之前也踩过这个坑，后来发现光靠system prompt不够，得在user prompt里把原文用明确标记包起来，比如“以下是参考资料，请只基于这些内容作答”，再配合few-shot给个正反例效果会稳很多。分段塞确实比整段好，尤其原文长的时候，模型注意力容易分散，你可以按语义切成几个小块，每块前面标个编号，让它在回答里引用编号。另外如果还乱编，可以试试把temperature调低到0.1左右，代

几万条记录真不用纠结性能，Chroma本地绰绰有余，我跑了半年多快十万条也没觉得慢。Milvus那个分布式配置光看文档就劝退，一个人搞纯属给自己加戏。MCP里Chroma有现成工具封装，跟function calling配合挺顺的，Milvus还得自己写不少胶水代码。倒是建议你后面真上规模了再换也不迟，反正接口都兼容。

我之前也踩过类似的坑，最后定位下来问题其实出在chunk切分和prompt的配合上。256字符对中文来说太碎了，经常把一个完整逻辑块拦腰截断，检索出来的片段单独看相关，拼起来就前言不搭后语，模型只能硬着头皮“脑补”。你试着把chunk调到500-800字符，并且加一个overlap，至少保留段落间的承接关系，效果会明显改善。 另外你说“仅基于上下文”约束太死，这个我特别有同感。我当时的做法是改成

我之前也踩过这坑，固定窗口切分对技术手册这种强结构文档确实容易把语义拆碎。后来改成了先按标题和目录做结构解析，再对每个小节内部用滑动窗口，效果明显好很多。另外你提到相关性打分还行但答非所问，我觉得检索阶段可以试试混合召回，比如加个BM25权重，跟向量分数融合一下，能压掉不少“看着像其实跑题”的结果。 还有个小建议，bge-large对这种长尾技术词可能不够敏感，有条件可以微调一下或者换个领域模型

说实话，几千页的企业文档用固定chunk_size本来就容易出问题，跨章节的内容被硬切断了，embedding再强也白搭。我建议你先试试按文档结构（标题、段落）做语义切块，别死磕字符数。另外text-embedding-3-small对中文长文本确实一般，有条件换个bge-m3或text-embedding-3-large对比下效果。BM25混合检索值得加，尤其处理那些专业术语和精确匹配的场景，能

这问题我之前也踩过坑，ResNet50直接提特征做检索，召回率卡在60%太正常了。你试试把输出层去掉，用倒数第二层的feature map做全局池化，比直接用2048维那个分类前的向量要稳得多。另外L2距离对图片这种高维特征其实不太友好，换成余弦相似度或者先做PCA降维到256维再检索，效果会明显好一些。还有个细节是Milvus的索引参数，HNSW的M和efConstruction调大点，召回能再

我也遇到过一模一样的坑，后来发现问题往往不在chunk大小，而是embedding本身没区分好语义相近的段落。你试试先做一下query改写，把用户口语问题转成更贴近文档的表述，效果会明显很多。 另外Agent的system prompt里得明确告诉它“只能基于检索内容回答，找不到就说不知道”，不然LLM很容易自己脑补。Chroma的相似度阈值也可以调严一点，低于0.7的直接不返回。 我后来换成

工具描述确实得写细点，但更关键的是得在数据里混入工具结果回填的多轮样本，纯单轮对话模型学不会状态跟踪。

这问题我也踩过坑，MCP现在确实各家实现比较放飞。我之前是直接写了个类型守卫，把messages和text还有resource都归一化成内部统一的Prompt对象，虽然也逃不掉if-else但至少收敛在一个文件里了。官方好像对这块还没定死规范，目前看社区里也没有特别成熟的解析库，倒是有人提议用zod做schema校验加转换，你可以试试这个思路。

4090跑8B确实卡在显存带宽和容量之间，我试过用AWQ配合vLLM的--kv-cache-dtype fp8能省不少，但延迟高多半是因为vLLM默认预分配了太多显存给KV cache，你把gpu_memory_utilization调到0.85以下试试，单请求延迟会明显降下来。量化损失这块，代码模型对token级依赖特别敏感，我拿CodeLlama-7B做过对比，4bit下它的语法正确率掉得比通

说实话这个坑我也踩过，而且踩得还挺深。我之前做意图识别的时候，试过把角色设定写得特别详细，结果模型在客服场景里居然自己脑补出一套“公司规章制度”，回答得特别正经但完全是编的。后来我干脆把模板拆成两层：一层是系统级的固定指令，只约束语气和输出格式，另一层才是动态插入的业务上下文，这样至少不会让模型在角色扮演上放飞自我。 至于现成模板，我建议别直接抄，因为网上那些大多是针对通用对话优化的，跟你具体业

试试把任务类型和Agent能力做硬绑定，在Graph里加个路由节点，别让主Agent自由发挥。

说真的，7B模型在客服场景下对Prompt格式的敏感度比想象中高得多，我踩过同样的坑。建议你把系统提示和用户问题用明确的标记分开，比如“###指令###”和“###用户###”，并且每条问题都带上示例输出给模型参考。温度设0只是降低随机性，但推理路径本身还是可能漂移，尤其长对话时最好把历史轮次截断到5轮以内。另外试试把“不要重复”改成“如果信息不足，直接回答不知道”，对减少复读机现象有奇效。

我最近也踩过这个坑，LangGraph的状态传递机制其实蛮反直觉的，节点之间共享的memory state是“快照”式的，不是实时共享，如果你在子Agent内部修改了state字段，但没显式返回新的dict，外面根本感知不到，尤其是三个Agent串行跑的时候，后一个拿到的往往是上一个节点执行前的旧状态。我当时排查了半天，最后发现是子Agent里的tool调用改了状态却没return，导致LangG

两张A100跑7B还OOM确实不太正常，大概率是vLLM的KV cache和显存分配策略没调好。你可以试试--gpu-memory-utilization设为0.9，再把--max-num-batched-tokens压到2048左右，吞吐虽然降了点但至少能稳定跑。另外如果支持AWQ的话，量化到4bit能把显存占用砍掉一大半，响应速度反而可能更快。我之前在4090上跑类似模型就这么干的，效果挺明显

分块前先做版面分析挺关键的，表格和段落混在一起，光靠切字数肯定乱套。 rerank是真有用，别省那点延迟，直接上bge-reranker试试。