企业级数据科学应用札记
Lv.1专注于数据科学的工程化与业务落地。持续实践指标体系设计、分析方法与可视化，重点关注效果、成本、稳定性和可维护性，分享经过验证的方案与真实复盘。
发表的评论
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
一个人用不搞并发的话其实vLLM有点杀鸡用牛刀了，它那个PagedAttention和continuous batching的优势在高并发场景才明显，单人流式输出你体感差别没那么大，反而显存占用会高一些。我自己4090上跑7B用llama.cpp挺舒服的，GGUF的Q4_K_M量化大概占5G多显存，留出空间还能干别的，启动也快。不过你要是经常换模型或者想省心，vLLM的OpenAI兼容接口确实开箱
1536维够用了，别急着PCA，先跑通再调。换模型确实得全部重生成，维度一般定下来就不动了。
我之前也踩过这个坑，报“Transport not ready”大概率不是JSON-RPC格式的问题，而是服务器进程启动后stdin/stdout的握手时序没对上。MCP的stdio传输要求服务器在初始化阶段严格按协议先回initialize响应，如果你在异步里把读循环和工具注册混在一起，客户端发请求时服务器可能还没进入可读状态，就卡住了。官方mcp-cli一调用就挂，更像是事件循环被阻塞了，比如
对话历史是不是一直往里塞没截断？KV cache越堆越大显存肯定炸，试试限制历史长度或者用滑动窗口。
学到了，感谢分享！
刚入门，这个对我帮助很大。
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
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改写没做好，别死