持续研究复盘实践笔记

我走过类似的路，后来发现关键不在LangGraph还是PyTorch，而在推理服务那层。把本地模型包成OpenAI兼容的API（vLLM或TGI都行），LangGraph那边几乎零改动，状态机、工具调用上下文全都不用自己管。自己用PyTorch重写整个流程，等于把LangGraph已经解决的调度和记忆问题再踩一遍，不划算。除非你的Agent逻辑特别简单，否则别为了推理去重写编排层。

2000条数据确实偏少，loss卡2.3可能是过拟合了，建议先查查数据里有没有大量重复或格式混乱的样本。

我也踩过这个坑，bge-large-zh-v1.5 本身没问题，但你描述的这个症状特别像 chunk 切得太“干净”了，512 对纯段落还行，一旦文档里有表格、标题层级或者对话式内容，embedding 拿到的语义就是碎的。多轮对话飘还有个隐藏原因：你把历史 query 直接拼进去做检索，embedding 模型对“拼接后的长 query”其实并不敏感，反而稀释了当前问题的核心意图。可以试试先把多

我之前也踩过这个坑，top-k拉大确实容易混进噪声。后来试了先用LLM对query做个意图拆解，再拿子问题去检索，命中率提升挺明显。另外bge模型可以试试加个bge-reranker做精排，比MMR稳一些，就是多一步推理延迟。你那边知识库文档结构规整吗？如果标题层级清晰，检索时把标题路径拼进chunk里也能帮忙过滤。

我也遇到过这种情况，感觉不是prompt的问题，而是模型在多轮修改时会“失忆”，把之前定义的变量名和结构都搞混。我的经验是别在同一个对话里反复改需求，宁可新开一轮把完整上下文重新贴一遍，反而更稳。另外迭代时我会先把当前代码和报错一起丢给它，让它只改指定那几行，别让它自由发挥。说到底它更适合从零生成，修修补补还是得自己盯着点。

我之前也遇到过类似情况，后来发现光靠Prompt确实不够稳。可以试试用LangGraph把流程拆成节点，工具调用作为独立步骤，状态显式传递，这样顺序乱了也能靠图结构卡住。另外给每个工具加个前置条件校验，不满足就直接跳过或返回错误，能减少乱跑的概率。

我遇到过，给每个工具调用加个独立上下文隔离就行，别让它们共用一个返回槽。

显存慢慢涨大概率是内存泄漏，检查下有没有没detach的张量累积在list里，混合精度有时确实会多占。

这个我也遇到过，感觉模型有时候就是会“自作主张”帮你优化命名，尤其变量一多它就开始偷懒。我的经验是把命名规范单独写一段，再给一个简短的命名示例，比如“所有原始数据统一用df_raw，输出统一用result_list，不要用df/data/results”，效果会好不少。还可以在末尾补一句“如果必须改名字，先说明原因”，它一般就不太敢乱动了。

你这个问题太典型了，我踩过一模一样的坑。光写“基于以下文档回答”基本等于没约束，模型会自己脑补。建议在system里加三句话：只允许用给定文档、有冲突时以标注时间新的为准、文档里没有的直接说“资料未提及”。另外把top5按相关度标上序号，让模型优先引用前两条，啰嗦问题会好很多。

vllm里max_model_len别直接拉满，得看模型原生支持多长，硬超容易显存炸。rope_scaling用YaRN确实能扩，但要注意vllm版本和模型config得对上，不然白调。我之前也踩过类似的坑，后来发现是MCP传参那层把max_tokens和max_model_len搞混了，检查下请求体。另外4000就报错的话，先确认下是不是tokenizer算出来的实际长度比你以为的多不少，中文尤

2 token/s确实太离谱了，4090跑4bit的7B怎么也不该是这个数。你GPU利用率不到30%基本能说明瓶颈不在算力上，大概率是请求压根没喂饱显卡，或者中间有什么同步阻塞在卡着。先确认一下你是不是直接用transformers的generate在FastAPI的async函数里同步调用，那样会把event loop堵死，并发测试的时候尤其明显。另外单轮对话如果也是2 token/s，那跟并发

我现在的做法是短期记忆直接用滑动窗口加摘要，每轮把最近几轮完整保留，更早的压缩成一段任务状态摘要塞回去，效果比全量拼接稳不少。长期偏好那块单独存向量库，但别每轮都检索，只在话题切换或者用户提到“上次那个”的时候才触发召回，不然反而干扰当前任务。开源的话可以看看MemGPT和LangGraph的checkpointer，前者记忆分层思路挺清楚，后者做状态机式的短期记忆比较顺手。全塞上下文肯定不行，t

固定chunk 500对PDF来说坑挺大的，表格和跨页段落很容易被切碎，召回阶段就已经丢信息了，后面重排再牛也救不回来。建议先拿badcase看看是切分问题还是语义匹配问题，别急着上微调。parent-child结构确实值得试，用小块召回、大块喂给LLM，配合元数据过滤（章节、页码）能砍掉不少噪声。微调embedding投入产出比一般，除非你有大量领域标注对，不然先把切分和检索链路捋顺更划算。

检查一下有没有在训练循环里累加loss或者把每个batch的output存进list里，这种写法特别容易让计算图越堆越多。另外自定义Dataset里如果每次__getitem__都创建新tensor并挂到某个全局变量上，也会涨。可以装个torch.cuda.memory_summary()或者用nvidia-smi -l 1盯着看，一般能定位到是缓存还是真实占用。还有别忘了验证阶段加torch.n

MCP上得手动设MASTER_ADDR和端口，不然init_process_group准挂，官方教程那套环境变量它不认。

我最近也踩过这个坑，后来把上下文按相关度从高到低排列，并且在每个chunk前加一句“以下片段仅供参考，可能不完整”，模型硬凑的情况少了不少。多文档冲突的话，可以在prompt里让它优先采用来源更明确或时间更新的片段，别指望它自己判断。让模型说“信息不足”确实难，我一般会在指令里加一句“如果上下文无法支撑答案，直接回复无法确定”，配合few-shot效果比纯指令稳。

我一般把规则拆成几个小函数调用，每轮强制模型只输出结构化字段，漂移就少很多。

试试用状态机约束解码，光靠堆数据容易过拟合。参数名出错可能是tokenizer切分问题，检查下特殊符号。

4bit量化得把模型转成bnb格式，直接load原版肯定报错，建议先看官方example。