认真做商业随身笔记

说实话你这情况我太熟了，之前调ChatGLM的时候也栽在多轮和复读上，后来发现核心不在LoRA参数，而是数据里多轮上下文的比例太低。你想想，5000条清洗后3万轮，但每段对话的平均轮次可能就6、7轮，真正超过10轮的复杂链路估计没多少，模型自然学不会长程依赖。 我建议你先做个简单的数据诊断——把“复读用户消息”的bad case拉出来，看看是不是集中在那些用户问法跟训练集里某个高频query很像

这题我踩过坑，你担心的点确实存在。我当时是直接把RAG的query+context拼一起做指令微调，用LoRA只调attention层，效果比全参数微调稳很多，最后生成时加了个“只依据给定资料回答”的系统提示，脑补情况少了大半。负样本这块，建议把检索到的相关段落和无关段落混着放进训练集，让模型学会对无关内容说“不知道”，比纯堆正确样本管用。另外微调时学习率调小点，1e-5左右，不然真会把原有知识冲

说实话我最近也踩过类似的坑，后来发现问题多半出在“边界条件”写太死，模型光顾着遵守格式反而忽略了内容本身。你可以试试把few-shot示例砍到只剩一两个，但把输出字段的定义写得更口语化，比如“主题就用三五个词概括，别整长句”。另外JSON错乱的话，试试在prompt末尾加一句“直接输出JSON代码块，别加任何解释”，比堆一堆规则管用。我感觉模型对“明确指令”的敏感度远高于“详细描述”，你精简到核心

试试让模型先逐条引用原文再回答，能明显减少编造，另外加个温度调低到0.2的配置。 检索噪声大的话，可以把top_k调小点，或者用重排序模型过滤一遍再喂给prompt。

A10跑7B AWQ这个速度确实偏低了，但网上那些40-50的数据多半是A100/H100或者纯生成场景的峰值，不能直接对标。你试试把并发降到1-2看单流速度能到多少，如果还是20左右，大概率是量化后显存带宽瓶颈，A10的显存带宽本来就不算强。另外检查下vLLM版本，老版本对AWQ的kernel优化差异很大，升级到最新版再跑一次，有时候能差出50%以上。多轮对话首token3秒的话，可以看看是不是

同感，我研一也是TF1.x入坑，后来转PyTorch就再没回去过。但说实话，与其纠结哪个学得更透，不如先把核心的模型结构、训练逻辑想明白，框架只是工具。你现在两边都沾，其实反而逼你理解了框架之间的共性，比如session和autograd本质都是计算图，只是表达方式不同。如果时间紧，建议以PyTorch为主深耕，TF那边够复现就行，毕竟论文代码迁移和部署都是后话，等真到工业界再针对性补也不迟。

这问题我也踩过坑，Claude对MCP的prompt参数解析确实不太聪明，建议在客户端用正则校验兜底，别指望模板描述能完全约束它。

说实话你这个数据量其实挺尴尬的，几十万条文本真不算大，但又不是小到能用内存硬扛。我当初也在这俩里纠结过，最后选了Qdrant，主要是图它docker-compose一键起服务，本地调试省心太多。Milvus那套依赖etcd和对象存储，光配置就能劝退新手，而且你如果只是单机跑，它的分布式优势根本发挥不出来。召回率这块其实更多取决于embedding模型和分块策略，向量库本身差距真没你想象的那么大，我

大概率是分块问题，500字对技术手册太粗了，试试按标题切块或者用父子块，BGE中文环境也明显好一些。

我之前也踩过这个坑，重点不是init_method，而是看你DDP的初始化到底在做什么。你确认一下是不是每个进程的rank和world_size都设对了，还有`torch.cuda.set_device(local_rank)`有没有在construct DDP之前调用，这个顺序错了梯度reduce会直接失效。另外PyTorch 1.12配CUDA 11.6的话，建议直接升到1.13或2.0，老版

之前我们上线也遇到过类似情况，后来发现根因不在重排，而是召回阶段就丢了关键信息，重排只是矮子里拔将军。建议你先别急着微调embedding，把BM25和向量检索的结果做融合，很多口语化query靠关键词反而更稳。另外你提到的幻觉问题，我猜是重排分数虚高把错误片段顶到前面了，可以试试在生成前加一道事实校验，或者直接对比原文看片段是否真的支持回答。

这个问题我最近也踩过类似的坑，特别是跨文件引用那块，光加路径前缀确实没用，模型根本分不清哪个片段是定义、哪个是调用上下文。我后来是把检索粒度改成了“文档块+关联链接”的方式，就是每个函数或类的chunk里，额外塞进去它被引用的位置（比如调用处的代码片段摘要），相当于把关系图谱的信息也揉进embedding里，召回率会好一些。另外你提到参数被编造，这很可能是排序问题，如果召回的片段里没有直接的参数说

这题我熟，6B模型压根没到能靠prompt硬控的程度，换7B以上的或者上RAG把知识库检索结果直接塞上下文里。

先别急着换embedding，BGE-M3配512的chunk对长文档确实容易漏细节，把chunk缩到256再调下检索策略试试。

我之前做知识库也卡在这俩上，最后选了LlamaIndex，主要看中它对索引和检索的抽象，自研向量库接起来确实省心。LangChain流程搭得快，但版本一更新，网上代码就废一半，后期改检索逻辑确实有点被绑住的感觉。俩混着用我试过，LangChain做agent编排，LlamaIndex单独管索引，目前没出啥大问题，但得自己维护好接口，别让数据流绕晕。你这文档量两万多份，建议先拿一小批测试下检索效果，

是不是没做rerank？召回和排序是两回事，光换embedding解决不了精排问题。

这现象太典型了，我调过类似的场景，2e-5对8B基座做全参数微调确实偏高，尤其你才2万条数据，模型很容易把新任务和语言分布强行绑定。法律摘要效果还行是因为它只管输出特定格式，但通用能力被覆盖是必然的，本质上是灾难性遗忘，不是单纯“数据少”能解释的。 我建议你先试试把学习率降到5e-6，同时把epoch砍到1-2，看看通用能力回不回得来。如果还不行，那大概率是数据分布太偏了，中文法律文本的句式和你

固定512字符确实太粗暴了，你这个问题我当初做产品手册问答时也踩过坑。跨页内容被硬生生切断，top_k调到10反而容易把不相关的段落也拉进来，噪声更大。我觉得你换父子分块的方向是对的，父块可以按章节或者连续几个段落来切，子块保持512左右，检索时用子块匹配但返回父块内容，这样上下文完整，速度和精度都能兼顾。语义分块不用怕慢，其实对几十页的文档，一次性embedding也就几秒的事，你可以在离线阶段

试过把历史query抽出来单独存成摘要再拼进去，召回确实干净不少，但摘要本身也会丢信息。 可以试试把每轮检索到的文档ID存下来，当前问题先分类，再决定要不要带历史字段进去。

遇到过类似的坑，后来我发现光在prompt里强调没用，得让输出格式“无路可走”。比如直接让Claude返回一个只有JSON的代码块，然后你在MCP那边用正则提取代码块内容，比让它“裸输出”稳得多。另外也可以试试把模板改成“直接输出JSON.parse可解析的内容，任何多余字符都会导致程序崩溃”，带点后果描述有时比单纯禁止更有效。如果还是乱加，就在下游做个二次校验，解析失败就自动重试一次，成本也不高