发布等待重构工程日常

说实话你这情况我太懂了，当初我搞图文检索时也卡在框架选择上纠结了一个礼拜。MCP对PyTorch的支持确实更丝滑，特别是你要用CLIP这类模型，torch的huggingface生态基本是零成本接入，而TF那边虽然也有ViT，但算子兼容性偶尔会给你整出点幺蛾子。不过你提到SavedModel部署省事，这点我不反驳，但多模态微调阶段你就知道PyTorch的灵活度有多重要了，梯度检查点、自定义损失函数

说实话这个坑我也踩过，vllm默认的max_model_len跟实际能跑的长度有时候对不上，尤其是用了rope_scaling之后，如果ratio没调好，显存反而会飙升得更快。我后来试了在启动vllm时显式设置--max-model-len 8192，同时配合--rope-scaling dynamic --rope-theta 10000，这样至少能稳在6k tokens左右，再长就得看模型本身

这个坑我也踩过，感觉微调的目标其实不是让模型死记片段，而是学会“怎么用”片段里的信息来修正自己的回答逻辑。数据构造上，“问题+片段+答案”确实容易出问题，尤其是检索质量差的时候，模型会把错误信息当成真理。我后来试了在训练时加一些检索不到正确内容的负样本，让它学会说“不知道”或者主动求助，效果反而稳了很多。另外LoRA的rank别设太大，不然通用知识掉得飞快。

你这情况我也遇到过，后来试了试把检索结果拆成“文档1-3”并加上简短的一句话摘要，再让模型按优先级逐段参考，效果好了不少。另外在prompt结尾加一句“请先仔细核对每个文档的原文再回答”也能减少编答案的情况，你可以试试看。

微调确实容易让模型更依赖内部知识，可以试试在训练数据里混入一些通用语料来平衡。

这问题我太熟了，前段时间做类似的方向，也是技术报告里的表格数据各种翻车。你提的chunk切分影响上下文确实是个核心点——20-30页的PDF，如果按固定长度硬切，表格很可能被拆到两个chunk里，模型只看到半张表，那漏数据几乎是必然的。建议你试试基于文档结构的切分策略，比如把表格单独识别出来作为一个独立chunk，或者至少保证一个完整表格不被切开，LangChain有个RecursiveChara