机器学习研究笔记

MCP Server确实是单独跑一个进程，通过stdio或SSE跟客户端通信，模型侧只负责发出调用意图，真正执行在Server那边。跟Function Calling最大的区别是工具定义和调用逻辑从模型服务里解耦了，你换模型、换框架都不用重写那堆schema。我之前也是手写JSON schema写到吐，接了几个MCP Server之后确实省事，尤其是社区现成的工具直接拿来用。不过坑也有，进程管理和

403和验证码基本说明人家已经识别出你不是正常浏览器了，光靠随机UA和sleep确实不够，这套组合几年前就不好使了。你现在这个阶段，加代理池和上Selenium其实解决的是不同层面的问题：代理池是绕IP封禁，Selenium是绕行为检测，但如果目标站点有比较强的指纹识别，Selenium裸跑一样会被拦，还得配合undetected-chromedriver或者playwright改指纹。我的建议是

状态别塞全局dict，用Redis按session隔离存，MCP的Resource其实挺适合挂这层上下文。

先让LLM把“那它价格呢”改写成完整问题再检索，比硬塞历史靠谱多了。

几万条向量Chroma完全够用，别折腾Milvus了，等真到百万级再迁移也不迟。

单卡4090跑LLaMA3-8B的LoRA还OOM，基本就是没用QLoRA的锅，8B模型全精度加载权重加上优化器状态，24G根本不够折腾，换成4bit量化加LoRA能省一大截显存，再把cutoff_len控制在512到1024之间，应该就能跑起来了。2万条客服对话不算少，关键看你怎么用，如果全是重复的模板话术那确实不够，但如果覆盖了足够多的意图和场景，配合数据增强是能出效果的。直接拿历史工单当训练

同感，这个“上午下午跑出来不一样”真的太真实了，我一开始也以为是玄学，后来发现主要是API侧模型版本在悄悄更新，还有缓存和并发请求的差异。分类任务我建议温度直接设0，别用0.2，0.2在边界样本上会给你随机挑一个次优标签，反而让准确率抖动更明显。few-shot放system还是user其实影响没那么大，关键是例子要和当前输入分布一致，你塞20个真实对话如果里面噪声多或者标签边界模糊，模型会被带偏

先别急着换模型，查查是不是query里“退款”和“退货”没做同义词扩展，bge-m3对中英混其实还行。

感觉你这个问题不一定出在embedding模型上，ada-002和bge-small虽然风格不同，但基本语义区分能力还是有的，不至于把超时和备份搞混。512字符的块对技术手册来说确实偏长了，一个块里可能同时塞了好几个主题，向量被平均之后反而谁都像、谁都不像。你可以先试试把块缩到200-300字符，再加一点重叠，看看召回有没有变化。另外纯向量检索对“怎么处理”这种带意图的问法本来就吃亏，建议加上BM

这个挺正常的，我一开始也踩过同样的坑。在线API背后大概率是72B甚至更大的模型，而你本地跑的是7B，参数量差了一个数量级，指令遵循和语言组织能力本身就有代差，这不是Prompt能完全抹平的。另外Q4_K_M量化确实有影响，尤其对格式稳定性和长输出质量，你可以试试Q5_K_M或者Q6，16G内存跑7B应该还能撑住，就是速度会慢一点。Prompt层面我自己的经验是，本地小模型特别怕复杂指令堆一起，你

7B模型单卡放不下就FSDP，显存放得下DDP更省心，看你这边的卡数吧。

我最近也踩过这个坑，后来发现关键不是指令多不多，而是检索片段本身有没有被模型“认出来”是答案来源。我现在的做法是把召回内容用固定分隔符包起来，前面只留一句“只根据下面内容回答”，few-shot反而删了。指令堆太多模型会把注意力分到格式约束上，忽略语义匹配。你可以试试把上下文按段落加编号，让它引用编号来答，效果会稳不少。

300行就崩说明你该上RAG或者分块了，光靠prompt压不住，工具链层面做摘要压缩才是正路。

“苹果公司”搜出水果食谱，这个其实挺典型的，不一定是索引参数的问题。pgvector的HNSW调m和ef_search主要影响的是近似搜索的精度和速度，但如果你top20里混进来的东西语义上就完全跑偏，那大概率是embedding空间里这俩本来就挨得近。OpenAI的1536维向量对中文语义的区分度其实一般，尤其是这种一词多义的场景，模型本身就没学好“苹果”在不同上下文里的区分。你换bge-lar

500条数据微调bge确实有点悬，模型很容易过拟合到那点样本上，反而丢了预训练学到的通用语义能力，召回掉很正常。我试过类似规模的数据，最后发现加个cross-encoder做rerank效果更稳，成本也低。你可以先把学习率降到1e-6再试一轮，但说实话小领域场景我更推荐先上reranker，微调可以等数据攒到几千条再说。

这事儿真不怪你提问方式，Cursor的Chat模式确实有这毛病，上下文窗口虽然大，但它对变量命名的记忆优先级特别低。我试过同一个会话里反复强调用df_raw，结果它第三次生成时还是偷偷换成data。后来发现一个比较管用的笨办法，就是每次让它改代码前，先把当前完整的变量列表或者关键几行贴进去，然后加一句“只允许用这些变量名，不许新建”。另外它生成清洗逻辑时特别喜欢自作主张搞中间变量，你可以在prom

握手失败大概率不是协议版本的事，MCP目前对模型版本没那么挑。你先确认vllm暴露的是OpenAI兼容接口，MCP server里base_url有没有写成容器内的localhost，Docker里那个localhost指的是容器自己，得换成宿主机IP或者用host网络模式跑。我之前也卡在这，日志里看着像握手失败，其实是请求根本没连上模型。建议把MCP server日志级别调到debug，看它到底

几千条数据10个epoch loss卡在2.3，感觉更像是数据本身的问题而不是超参。你检查一下对话里是不是有很多重复模板或者回复太短，LoRA对数据质量特别敏感，垃圾进垃圾出。另外学习率1e-4对7B模型其实偏高了，可以试试2e-4配cosine schedule再看，但别指望loss降太多，对话任务的loss本身就不会很低。alpaca格式主要是instruction-following，开放域

我之前也踩过这个坑，后来发现光靠system prompt强调“记住历史”基本没用，模型该忘还是忘。比较有效的做法是把中间结果结构化成JSON塞进下一轮的observation里，比如订单状态、是否延迟、用户ID这些字段，让它每次都能看到。另外ReAct的prompt里最好把工具调用的格式约束死，用few-shot给两三个完整的多步例子，比单纯说“逐步思考”管用得多。

用LangChain的structured output或者Pydantic parser试试，比让模型裸奔JSON靠谱不少。我一般会开个fallback chain，解析失败就把原始输出丢给一个小模型重新格式化，比纯try-catch重试省心。CrewAI底层其实也依赖类似机制，换框架不一定能根治，关键还是约束输出格式。