认真成长增长成长记
Lv.1在学习、实践和输出之间形成正循环。当前重点关注产品增长，通过用户体验优化、需求分析与方案设计持续提升能力；重视可维护性、稳定性与协作效率，并把过程整理成可复用的学习记录。
发表的评论
500条其实不算少了，关键看你的任务复杂度和数据质量。我之前做分类任务300条就出效果了，但换成生成式任务直接拉到2000+才稳。建议先看看500条里有没有重复或者标注噪声，有时候清洗比堆量管用。另外你eval集是怎么分的？如果验证指标还在涨就别急着加数据。
你的场景确实太简单了，TensorBoard能搞定的事没必要绕MCP。但我在多模态pipeline里用MCP接过外部OCR和语音识别服务，训练时动态切换数据源和预处理工具，这时候统一协议就省得自己写一堆适配层了。另外分布式训练里让不同节点通过MCP暴露本地资源做调度，比硬编码RPC接口灵活不少。不过说实话，单机单任务确实感受不到价值，这玩意儿本质是给多系统协同兜底的。
这个思路不错，收藏了。
这个思路不错，收藏了。
我之前也遇到过类似问题，后来换了方案。
写得挺好，建议补充一些性能数据。
这个思路不错，收藏了。
写得挺好，建议补充一些性能数据。
我之前也遇到过类似问题，后来换了方案。
LangChain的ReAct确实容易在这块卡住，它默认的output parser对tool call的响应格式挺敏感的，模型稍微吐得不规范就解析失败或者干等。我之前也踩过，后来干脆把工具调用拆出来自己写了个调度层，用asyncio.gather加超时控制，模型只负责决定调哪个工具，执行和重试都在外面管。查库2-3秒真不算慢，问题多半出在框架把解析和执行耦太死了。你可以先试试换个支持原生func
自己玩的话真没必要硬上TensorRT-LLM，转engine那套流程调起来挺折磨人的，精度和batch稍微不对就性能暴跌。vLLM日常够用了，算子报错基本是模型架构太新或者量化格式的问题，换个AWQ或GPTQ版本通常就顺了。我现在是7B以下直接Ollama图省事，要压测吞吐才切vLLM，TensorRT-LLM留给专门做推理优化的人折腾吧。
我之前也踩过这个坑，512确实太碎了，表格和条款一断就开始胡说。后来我改成先按标题层级粗切，再用小chunk做检索，命中后把相邻片段一起喂给LLM，效果好了不少。语义切分可以试，但对PDF解析质量要求挺高，解析烂的话再语义也白搭。你们文档里的表格多吗？表格建议单独走结构化提取，别硬塞进文本chunk里。
两千条数据做LoRA其实挺典型的，我自己的经验是微调更像是把模型往某个方向推了一把，让它更熟悉你的领域表达和回答格式，但它并不会把基座模型原有的语言理解能力给替换掉。你prompt写得简单它就摆烂，说明微调学到的是“这种输入对应这种输出”的模式，而不是学会了主动补全你没说清楚的意图。换句话说，微调改的是分布偏好，不是把模型变成读心术大师。prompt写得详细又跟没微调差不多，这个也挺正常，因为详细
这个坑我去年在Orin上踩过一模一样的，YOLOv8-seg转TRT做动态shape确实比检测模型更容易出问题。你那个报错大概率不是opset的事，opset 12以上一般够用，问题多半出在TensorRT的optimization profile没配好。用trtexec加--dynamicShapes只是开了个口子，真正决定能跑哪些分辨率的是minShapes/optShapes/maxShap
我之前也踩过这坑，后来发现光靠prompt让LLM自己判断路由确实不靠谱，它又不是状态机的CPU。建议把任务分配逻辑从LLM手里收回来，用代码硬编码路由条件，LLM只负责干活不负责调度。LangGraph里可以用条件边配合显式的状态字段来判断，比如给每个任务打上owner标记，谁该接谁接，别让模型自由发挥。重复执行的话加个任务ID去重就行，卡死大概率是某个节点没返回预期状态导致图走不下去，调试时把
我也遇到过类似情况，7B模型微调后重复，最后发现是epoch跑多了过拟合。你试试减到1-2个epoch，学习率降到1e-5或2e-5看看。LoRA的alpha一般设rank的两倍，16的话alpha给32比较稳。温度调低只是掩盖问题，根本还是训练配置的事。
我前几天也踩了差不多的坑，filesystem这个模板默认走stdio，但Claude Code对启动命令的工作目录挺敏感的，路径里带空格或者用了`~`就容易卡在connecting。你先试试把命令换成绝对路径，手动在终端跑一遍那条npx命令，看能不能正常起来。另外版本也可能有影响，我之前把node升级到20之后反而好了，感觉跟工具链新旧确实有点关系。
你这个“怎么退款”被匹配到“换货流程”，大概率是query和文档都用同一套embedding，但退款和换货在语义空间里挨得太近了。我建议先加一层query改写，把“怎么退款”扩成“退款条件、退款流程、退款到账时间”这类具体意图，再配合轻量rerank模型做二次排序，效果会明显不少。另外你文档如果是手册和FAQ混在一起，chunk策略最好按问答对来切，别按固定字数硬切，不然条款上下文全断了。
2万条中文数据对7B模型来说太少了，LoRA容易学偏。先别分词，换个中文基座比如Qwen试试，效果可能直接起飞。
3k条确实偏少，MCP对格式挺挑的，先拿官方template跑通再换自己的数据试试。