认真做产品实践笔记

我之前也踩过这个坑，LoRA微调时检索片段里混了噪声，模型直接学会了“抄错的”，后来我把训练数据里检索质量差的样本全筛掉，只保留高相关片段才好转。其实RAG微调的目标不是让模型背文档，而是教它怎么把检索结果和自身知识揉在一起，所以数据构造上最好加一些“检索片段不完整或矛盾”的负例。另外LoRA秩别开太大，我试过r=16就明显把通用能力带偏了，r=4或8更稳。

Agent场景下vLLM确实有点水土不服，它更适合高并发短请求，多轮工具调用这种带状态的交互反而容易把KV cache搞得很碎片化。我自己是换回了llama.cpp加GGUF格式，配合q4_k_m量化，7B左右模型大概占5G不到，留出空间给历史记录和工具返回，24G卡跑起来舒服很多。工具返回结果一定要做截断和摘要，不然一个API返回几千token直接把context吃满，我现在习惯在工具层就lim

日志乱写八成是没设local_rank做判断，DDP里每个进程都会跑一遍你的代码，得用rank区分。

我踩过一模一样的坑。后来发现500字里真正有用的可能就那两三句约束，其他角色设定、边界条件反而在抢注意力，模型顾此失彼就容易把JSON搞崩。结构化提取这种任务，few-shot给两三个高质量例子比堆一堆规则管用，规则越多越容易自相矛盾。你可以试试先只留任务描述加输出格式，跑一版看baseline，再逐个加约束，哪个加了掉分就砍掉。

跨段落的问题确实难搞，我后来是把chunk按文档结构切，比如按标题层级来，每个小节单独成块，再补一句所属章节的摘要进去，检索时命中率会高不少。固定token切很容易把本来关联的两段拆开，尤其是技术手册这种有明确层级的。另外重叠可以设大一点，10%-15%左右，别只给50。真要调好还是得攒个几十条测试query跑一遍，光靠感觉调不出来。

我踩过这个坑，后来发现光调top_k确实治标不治本。加个轻量rerank其实没那么吓人，用bge-reranker-base这种小模型，top20重排到top3，延迟也就多几十毫秒，线上完全扛得住。另外prompt里可以明确让模型“只依据最相关的片段回答，不确定就说不知道”，这招对擦边内容挺管用。多路召回反而容易引入更多噪声，先把rerank加上了再说。

我也被这问题折磨过，后来发现光在prompt里喊“遵守类型”基本没用，得把types.ts直接@进对话让它实时读。另外tab补全确实不太行，切到Composer的agent模式会好很多，它会主动去翻你项目里的类型文件。还有个小技巧是在组件文件顶部加个import type引用，AI看到具体路径后重新定义类型的概率会低不少。

建议先dump出飙nan前那几步的样本看看，大概率是脏数据或超长token在作怪。

我也踩过这个坑，最后是用 async/await 包了一层适配器，把 callback 和事件都转成 Promise，再用 Promise.all 或串行链控制依赖顺序，状态同步基本靠一个全局的 task registry 维护。超时的话每个工具调用都套 Promise.race，卡死问题就少很多了。MCP 目前好像没官方的编排方案，社区里有人提过用类似 Temporal 或 BullMQ 的思路

切分把实体和结论拆散了，rerank 再准也拼不回来，先试试按标题层级切或者父文档召回吧。

我也遇到过，多半是本地服务监听地址绑了127.0.0.1而Claude走IPv6，试试改成localhost或::1。 超时前先看下服务器日志有没有收到请求，没收到就是网络层问题，收到了再查响应格式。

这问题我踩过，session_id得在MCP server里自己维护，官方确实没管，配个Redis按session隔离最稳。 试过用context传参给工具做路由，但代码丑且容易漏，还是建议在server层做全局session管理。

简历问答这个场景，问题多半不在embedding和chunk上，而是简历里信息密度太高，固定256字很容易把不同项目的职责和技能糊在一起。建议先按语义段落切，比如用换行或标题做边界，再配合关键词加权，把岗位名称、技能词单独抽出来当tag走一遍BM25，效果可能比直接换模型来得快。rerank对中文长文档不是没用，但得看你的top5里不相关的是不是真的语义相近，如果只是关键词碰巧重合，那重排也救不了

个人感觉system prompt这个变量影响可能比你想的大，本地没加线上加了，模型输出分布直接就变了，尤其Qwen对格式指令挺敏感的。另外vLLM的采样确实和HF默认不完全一样，特别是top_k和repetition_penalty的默认值有差异，建议先对齐这两个再测。TP=4的话注意下A10的显存带宽，batch大了容易触发投机采样或者动态batch的精度抖动，试试把max_num_seqs调

先别急着上框架，手动编排逻辑跑通了你才知道哪些环节需要给Agent放权，不然换汤不换药。 工具链堆得越猛越容易掩盖核心问题，建议先拿三个真实对话案例硬啃，把状态机画出来再谈自主决策。

50万条真不大，pgvector够用，更新频繁就别折腾es了，混合检索先看效果再说。 faiss全量更新确实坑，换pgvector增量更新省心，中文场景bm25加向量提升挺明显的。

太真实了，prompt越“专业”模型越像戴了紧箍咒，我现在只写关键约束，剩下全靠它自己发挥。

试试把检索内容拆成“事实+引用”两段喂进去，再明确告诉模型“不确定就直说”，稳定性会好很多。温度调0.1以下，JSON模式对结构化输出帮助大，但别指望它解决幻觉。

分段这个事我建议你先别纠结固定tokens还是语义段，得看你的检索粒度是什么。你内部知识库，用户问的往往是“某个流程怎么走”或者“某段规范原文”，那按章节、条款这种自然语义边界切，召回以后上下文是完整的，比512硬切强太多。但如果你文档里全是表格、列表，语义边界不明显，那就得混合策略了——比如先按标题层级分块，块太大再往下拆，同时给每块加个“父块摘要”作为额外检索字段，这样召回时能匹配到上下文更宽

7B写TS确实费劲，类型推断跟不上很正常，换Qwen2.5-Coder 7B估计也差不多，8G显存还是老实配个规则校验吧。