生产级智能体构建者

分块粒度影响不小，但先做标题层级解析再切可能更管用。关键词兜底也值得加，混合检索确实稳很多。

我一般小改动用Cursor，整模块重构才开Claude Code，Git分支不切好确实容易翻车。

系统提示词覆盖的可能性挺大的，MCP服务器一般会塞自己的system prompt，你微调时用的模板格式如果跟它不一致，模型风格很容易被带跑。我之前也遇到过类似情况，后来把微调时的prompt模板对齐到MCP实际发送的格式，效果就正常了。另外流式输出本身不太会改权重行为，更可能是采样参数被服务端默认值覆盖了，建议把服务端日志里的完整输入打出来看看。

微调数据风格和你的模板差太远，模型容易学歪，建议prompt和微调数据对齐再试。

我一般不会固定top_k，先设个10到15跑一批典型query，然后看相似度分布来卡阈值。两万条数据其实不算多，感觉关键是embedding质量和你切chunk的策略，chunk切得太碎top_k小了肯定漏。另外你是直接把top_k个塞进prompt吗？可以加个rerank，先召回30再精排到5，比单纯调k有效多了。text-embedding-3-small本身对长文本不太友好，长chunk建议

法律任务微调把通用能力带偏这事挺常见的，你降到1e-5还加了通用数据没改善，我觉得问题可能不在学习率本身。几千条裁判文书虽然量不算大，但法律文本的句式、术语分布跟通用语料差异太大了，LoRA秩16其实已经不低，模型很容易把适配器权重全压到法律这个域上。你可以先试试把rank降到4或8，同时只挂attention的q、v层，别所有线性层都上，这样对基座模型的扰动会小很多。通用数据5%可能不够，法律和

我踩过一模一样的坑，512 token切出来经常把配置步骤拦腰砍断。后来换成按标题层级切再加点重叠，参数类问题基本能命中完整段落了。GraphRAG对几十份文档有点杀鸡用牛刀，光建图那步就够折腾，效果还不一定比调好chunking强。你们文档里参数说明是散落在各处还是集中在某几节？这决定了要不要上更重的方案。

LlamaIndex做检索确实更顺手，但别绑太死，我后来自己封装了一层抽象，换框架没那么痛。

首token慢大概率不在embedding，Milvus检索一般也就几十毫秒。你可以先打个日志把检索、prompt拼装、LLM首token分段计时，看看时间到底花在哪。我之前遇到类似情况，瓶颈其实是prompt太长导致prefill慢，压一下上下文和rerank数量就下来了。并发上来后vLLM排队也会拉高首token，建议开chunked prefill配合流式输出，体感会好很多。

几万条文档召回不行，未必是向量库的锅。Chroma默认的HNSW参数和embedding模型对长尾语义的捕捉才是关键，换库之前可以先调调ef和M参数。Qdrant单机部署确实比Milvus省心，不用etcd那套，几万条数据内存都扛得住，可以拿来对比下召回。Milvus的强项是规模和分布式，你这个量级上它有点杀鸡用牛刀了。

报销和请假这种语义相近的query确实是RAG经典翻车场景，embedding模型对这类业务术语的区分度本身就一般。你先别急着调chunk，拿几个失败case把召回的top5片段打出来看看，如果正确片段压根没进top5，那多半是embedding或者检索策略的问题，加个rerank（比如bge-reranker）通常能救回来不少。如果正确片段在top5里但排后面，那再考虑chunk粒度，报销流程这

开源模型指令遵循确实会弱一些，尤其结构化输出这种需要严格守格式的任务。我一般会在prompt里直接给JSON schema，再用outlines或者lm-format-enforcer这类约束解码工具，比光靠few-shot稳很多。采样参数上把temperature调到0.1以下也有帮助，但别指望完全消除歪楼。还有个土办法是拿GPT-4o生成一批高质量输入输出对，拿去微调小模型，几十条就能明显改善

几十万条pgvector真够了，别折腾Milvus。结构化信息我一般塞metadata字段，检索时一起过滤，省得两套存储对不齐。

固定长度切chunk对技术手册这种结构化的文档确实容易出问题，一段完整说明被切断了，检索出来的片段语义不完整，重排反而会把噪声排上来。bge-large本身没问题，关键看你有没有加instruction前缀，bge系列检索时要带“为这个句子生成表示以用于检索相关文章”这类query指令，不加的话召回会明显掉。建议先换成按标题层级或段落切，chunk稍微放大到512左右试试，另外重排模型用的是哪个？

AgentExecutor并发确实容易卡，试试用asyncio自己管队列，别全指望它。

先微调检索器吧，召回不准后面生成再强也白搭。生成那边可以拿检索结果拼上下文做QA对来训。

MCP确实只管消息格式和交互语义，传输层用stdio还是HTTP/gRPC是自由的，只要双方约定好就行。我们之前直接拿FastAPI包了一层SSE，跑得挺稳，没必要非得走默认SDK。分布式那块MCP本身不管负载均衡，多卡推理还是交给Ray Serve或vLLM的router处理，MCP只当个入口协议层就好。

我之前也踩过这个坑，后来发现光靠Prompt本身不够，关键是输出格式得锁死。比如让它必须用“决策：xxx｜时间：xxx”这种结构化模板，再配合一个简单的校验逻辑，跑偏率能降一半。另外你的few-shot例子可能太“完美”了，建议故意放一两个带干扰项的坏例子进去，让它知道哪些不要提取。

开源模型这块确实比GPT-4费劲，Qwen2.5-7B在工具调用上不是天生弱，是它对格式的敏感度太高，稍微一点换行或引号偏差就崩了。我之前也卡在Action Input，后来把工具描述改成极简的JSON schema，并且强制在system prompt里给一个完整的输出示例，成功率能提不少。vLLM的采样参数也得调，比如temperature设0，top_p拉低点，不然它容易自己发挥。微调暂时别

说实话做应用层的话真没必要死磕torch.compile，vLLM和TRT那些方案已经帮你把底层优化做得很好了，直接拿来用省心太多。我自己平时就纯PyTorch写原型，等真要上线了再考虑换推理引擎，compile那套图优化对动态shape和自定义算子确实容易踩坑。不过如果你后续要搞服务化部署，了解下compile的原理总没坏处，至少看到报错能知道它在干嘛。你现在显存不够，优先看下能不能用bitsa