月下读书集

7B模型单卡80G上ZeRO-3还OOM，大概率不是显存真不够，而是stage3的param partition在初始化时会把完整模型先加载一遍。你可以试试加`"stage3_param_persistence_threshold": 0`和`"stage3_max_live_parameters": 0`，或者直接用`from_pretrained`时指定`low_cpu_mem_usage=T

我前段时间也踩过差不多的坑，固定chunk确实很容易把一条完整的因果链切碎，检索出来每段都相关但拼不到一起。后来我改成先按文档结构切，比如标题、段落、列表项为边界，再对超长块做二次切分，效果比死磕chunk_size好不少。parent document retriever我也试过，关键不是父子块谁大谁小，而是子块要足够小去命中细节，父块要能覆盖一个完整语义单元，我一般子块300左右，父块1500

百万级ES的KNN内存扛不住，我们最后加了Qdrant，真香。

这个显存持续涨最后OOM的情况，八成是计算图没释放掉。你可以先试试在训练循环里每个step结束后手动加一句 del loss，然后 torch.cuda.empty_cache()，看看显存曲线是不是还往上飙。不过更常见的坑是你在验证或者可视化阶段又跑了一次forward，但忘了加 torch.no_grad()，这样每次迭代都会把新计算图挂在内存里，涨到12G太正常了。DeepLabV3+本身R

500条确实太少了，loss卡1.8基本就是模型没学到东西，10个epoch在这么小的数据上早就该过拟合了。你检查下数据格式对不对，Qwen2.5的chat template有没有正确套上，这个搞错了loss根本降不下来。另外2e-4对LoRA来说偏高了，试试1e-4或者5e-5，rank也可以拉到16或32。建议先把数据扩到至少两三千条，再拿几十条出来做验证看生成效果，别光盯loss。

我也有过这个阶段，后来发现把Prompt当代码来管理会清晰很多。建议先啃一下OpenAI的官方Prompt工程指南，再搭配LangChain或DSPy这类框架，它们把模板、示例选择、输出解析都结构化了。关键是要建立自己的评测集，每次改动都跑一遍看指标，不然永远在凭感觉。温度那些参数其实优先级不高，先把任务拆解和few-shot示例选对更重要。

500字符切太碎了，API文档按接口粒度切更好，不然上下文老丢。

这思路我觉得挺靠谱的，不算想多了。你本质上是在召回前加了一层“查询理解+路由”，MCP正好适合干这个，让模型先去查一下业务库或者搜索引擎，把query改写或者扩展得更准，再丢给向量库，垃圾chunk确实能少一截。不过要注意，MCP本身不解决召回排序问题，它更像是个前置过滤器或者上下文补充器，别指望它直接替代精排。我自己试过类似的路子，用工具先拉一批结构化候选，再和向量召回做融合，效果比纯向量好不少

数据才5000条还震荡，八成是没warmup或者数据没shuffle，先查这个吧。

这个问题我前阵子也踩过，确实挺烦的。MCP本身只是个协议层，它不会帮你管向量库的生命周期，所以文档一更新，老的embedding还躺在那儿，检索肯定召回旧内容。我当时的做法是在MCP server里加一个文档指纹校验，每次检索前先比对源文件的hash，变了就触发重新切片和upsert，同时把旧的chunk按doc_id删掉。但这样有个坑，就是删除和写入之间有个时间窗口，如果这时候来查询，可能两边都

我们之前也踩过这个坑，后来在检索前加了一层轻量query改写，把“他们的毛利率”结合上一轮补全成“A公司毛利率”，历史只留最近两轮做指代消解。检索结果也别一股脑全塞，按相关性阈值截断加去重，context能省一半。记忆压缩那套听着美好，但实际跑起来容易丢细节，不如把结构化信息单独抽出来存着。

几百万条Qdrant完全够用，生产也没问题。HNSW先默认参数跑，m=16、efConstruction=200基本不踩坑。

500条数据跑3个epoch，3e-4的学习率确实有点猛了，尤其是LoRA这种小参数量微调，很容易把预训练的知识带偏。你的情况八成是灾难性遗忘，加通用数据混合训练是最直接的办法，比例可以先试个1:3或者1:5，别一上来就全塞公司数据。r=8其实不算小，7B模型上够用了，问题更可能出在数据分布太窄，模型只盯着你那点术语，把原来的能力覆盖掉了。我之前也遇到过类似情况，后来把学习率降到5e-5，再混了通

几十万这个量级pgvector完全扛得住，别被那些文章带节奏了。我这边两百多万条向量用pgvector跑，建好HNSW索引后延迟也就几十毫秒，召回率也够用。真正要换的节点一般是过了千万级、或者并发查询特别高的时候，那会儿再迁移也不迟。专用库不是非得上GPU，Milvus这种CPU也能跑，GPU主要是建索引和超高QPS场景才划算。早期别给自己找麻烦，先把业务跑通再说。

这个思路不错，收藏了。

卡三天确实挺折磨人的，不过MCP这块坑是真不少，你遇到的情况我基本都踩过一遍。先别急着怀疑input_schema，那个改再多遍也救不了transport层的问题，因为stdio模式下只要stdout里混进一行非JSON的输出，客户端就直接解析失败报invalid request，超时往往也是这个原因——进程卡在某个地方没有正确flush或者阻塞在stdin读取上了。你可以在server入口加个日

gpu-memory-utilization=0.9本来就是按单卡总显存的90%去预分配KV cache，不是按模型实际需要多少来算的，所以你看到22G+完全正常。第二张卡没吃上大概率是tensor-parallel-size没生效，检查下启动日志里有没有TP=2的信息，或者模型是不是被判定成单卡能放下了。速度20 tokens/s偏低，先确认下是不是没开chunked prefill或者enab

这个坑我踩过，MCP本身只是负责协议层的收发，它不会帮你把JSON里的base64自动变成tensor，所以“Expected tensor, got dict”基本就是handler里拿到的是原始请求体，没做转换就直接喂给模型了。你需要在服务端的handler里显式做预处理，比如把base64字符串解码成bytes，再用PIL或者cv2读成numpy数组，最后归一化、转成torch tensor

这个现象其实挺常见的，我去年做金融问答时也踩过一模一样的坑。你那几千条内部问答对里大概率混了不少“直接给答案”的样本，模型微调后学会了跳过检索、自己凭记忆答，所以一接回RAG就开始无视文档。LoRA把模型往“业务风格”上拉的同时，也把它的“检索依赖”给削弱了，这两个目标本身是有拉扯的。可以试试在微调数据里专门构造一批“给定上下文再回答”的样本，让模型重新学会用文档说话，而不是靠参数记忆。另外检索器

政策文件这种结构强的文本，可以试试按条款切而不是按固定token数，比如按“第X条”来分，每块自带标题和上下文，召回会干净很多。bge-small换large在3090上其实还好，batch调小点推理速度能接受，中文效果提升挺明显的。重排序那步可以先不上，等baseline跑通了再加个bge-reranker-base试试，不复杂，效果提升比换模型还直接。