企业级数据科学应用札记

27%提升看着香，但跨栈任务才是试金石，等实测混合场景再吹不迟。

我一般会让Agent先把循环边界写死，比如明确“从第2行到第100行”，别让它自己算长度。还有个坑是它喜欢在循环里改列表，跑着跑着索引就乱了，这种情况让它用副本遍历会稳很多。你可以在prompt里加一句“每次循环后打印当前状态”，跑一遍看它卡在哪，比反复调措辞有效。

7B写TS确实容易翻车，类型推断太吃模型容量了。Qwen2.5-Coder会好点，但prompt里最好把语言和约束写清楚。

BGE-small对中文技术文档确实有点吃力，换BGE-m3或者bge-large-zh试试，召回能明显好一截。分块别死磕固定长度，技术文档按标题层级切会稳很多，512有时候一刀切下去语义都断了。reranker可以上bge-reranker-base，8G显存跑得动，top-20重排到top-3效果提升挺明显的。

我们线上就是MCP只做转发，模型走内部API，省心太多了。本地塞vLLM看着延迟低，但并发一上来显存直接炸，还得搞队列和限流，运维成本比省的那点延迟高多了。多版本的话建议在API网关那层做路由，MCP里按请求头带个版本标识就行，别让它管权重。真要本地跑也别把权重打进MCP进程，单独起推理服务用HTTP连，MCP崩了模型还在。

这个问题其实挺常见的，我自己也踩过不少坑。AI生成代码时默认走的是“happy path”，也就是假设一切输入都正常，异常处理在它的训练数据里往往是被省略的那部分，除非你明确逼它写。我试过在prompt里直接要求“每个可能抛异常的调用都包try-except，并且给出具体处理逻辑”，效果比只说“健壮性”好很多，因为后者太抽象了。另外有个技巧是让它先列边界情况再写代码，比如“先列出这个CSV处理函数

我理解你的困惑，MCP本质上是个协议层，不负责帮你统一数据格式。tokenizer和归一化这类预处理建议放服务端，客户端只传原始数据，不然每个调用方都得复刻一遍预处理逻辑，维护起来很痛苦。MCP里resource和tool的schema确实要自己定义，但好处是它能标准化工具发现和调用流程，比裸REST多了点“自描述”能力。你可以把MCP当成带元数据的RPC，别指望它解决tensor和JSON的映射

512的块配128重叠，加上bge-large-zh本身对长文本会有点截断，很可能问题不在Milvus参数上。你试试先把切块降到256/64，或者加个rerank步骤看Recall@10能不能直接涨一截。另外80万条数据用IVF_FLAT的话nprobe调太小召回确实会掉，可以扫一下不同nprobe下的曲线定位下。如果单条相似度分布正常但整体召回低，多半是chunk粒度或query改写没做好，别死

这问题我太熟了，本质上不是LangGraph的锅，是你把“业务约束”和“模型自由”混在一起了。只要让LLM自己在多个工具之间决定调用顺序，超过3个工具几乎必乱，因为模型没有全局的依赖图概念。我的做法是把库存查询和报价生成拆成两个显式的子图节点，中间用一个校验节点卡住，报价节点只有在state里拿到inventory_result之后才允许执行，否则直接短路回查库存。条件判断别塞在节点内部，用边上的

我试过第一种，token确实多但可控；第二种等于检索写死，复杂问题容易答偏，分块重排还是得自己搞。

我上周也试了下，感觉局部改确实比之前顺，但全局调性一变就容易顾此失彼。你说的参数空间映射我很有共鸣，实际用起来更像是它在几个预设维度里猜，猜偏了还不给解释。撤销这块我也挺好奇，连续改几轮后它到底记的是状态还是对话，回退时经常得重新描述一遍需求。

展台demo和量产之间差了一百个丢帧的SLAM，通用性听着美好，先把专用场景的良率干到99%再说吧。

200字符分块对API文档来说太碎了，一个接口的签名加参数说明很容易被切断，召回时自然拼不出完整语义。你可以试试按函数或接口为单位切，保留完整的docstring和示例代码，再在metadata里带上模块名和功能标签。另外“创建订单并处理库存回滚”这种问题本身就跨了多个概念，单纯靠向量相似度确实容易飘，加一层轻量的意图分类或者关键词预过滤会稳不少。

太正常了，我调的时候也遇到过，同一套提示词在Claude上像听话的实习生，换到GPT-4就开始自由发挥。后来我的经验是别迷信什么通用方法论，角色设定对Claude这种RLHF偏保守的模型确实更管用，但GPT-4更吃结构化指令和明确约束。所以现在我基本是给每个模型维护一套prompt模板，顶多把任务描述和示例抽出来复用，格式和语气各调各的。真要说通用原则，可能就是少让模型“自由发挥”，把输出格式和边

都2024年了还纠结这个真没必要，你们实验室师兄全用PyTorch就已经说明问题了。做图像生成和Transformer这块，PyTorch生态明显更活跃，HuggingFace和Diffusers库几乎都是PyTorch优先，调起来也顺手。TF Serving部署确实强，但那是上线阶段的事，科研阶段先跑通再说。建议直接PyTorch，然后去撸一遍minGPT或nanoGPT的代码，对着手写一遍Tr

试试限制单条请求的max_tokens和history截断，超长上下文才是OOM主因，量化救不了这个。

Qwen2.5-7B做结构化输出确实偶尔会飘，我自己的经验是光靠Prompt约束不太够，得配合推理框架的JSON mode或者grammar约束才稳。温度调到0.1以下能减少格式跑偏，但漏字段更多是模型对schema理解不够，可以试试把字段说明拆成注释嵌进JSON模板里，让它填空而不是自由生成。DeepSeek在这块比Qwen听话一些，尤其加了自检那步“输出前先检查字段是否齐全”会好很多，但会牺牲

几万条数据Chroma完全够用了，它慢主要是百万级往上才明显，你这个量级根本不用担心。Milvus单机版配置其实也没那么吓人，docker-compose拉起来就能跑，但对你来说有点杀鸡用牛刀。MCP集成方面Chroma的Python接口更轻，跟工具调用配合基本零折腾，Milvus客户端初始化稍微重一点。建议先用Chroma跑通，等真到瓶颈了再换，迁移成本也没想象中高。

全局state一个dict管到底，子agent只读写自己key，流程用Send显式触发，别依赖隐式依赖。

我之前也踩过这个坑，后来发现光靠system prompt压不住，得在user prompt里把原文用引号框起来，再明确加一句“如果找不到直接依据就回答不知道”。另外你可以试试把检索片段按相关性标号，让模型引用时带上编号，这样就算它自由发挥，你也能追溯到底引没引对。至于长原文，我建议分段塞，但每段前加个简短的标题提示，不然模型容易把上下文搞混，反而更爱瞎编。