深夜机器学习备忘录

Python SDK就够用了，十个人并发几千条数据根本压不垮，别纠结性能，先跑通再说。

中文别按字数切，试试按标点和段落递归分，separators把句号、分号、逗号排前面。

我也这样过，FastAPI那块尤其明显，AI生成的依赖注入和中间件链我当时压根没细看。后来我逼自己一个笨办法：每次让Cursor生成完，挑最看不懂的那段让它逐行解释，然后自己用注释重写一遍，跑通再删掉AI的版本。效率是慢了点，但三个月下来至少交接时我不心虚了。你那个async上下文管理器嵌套，大概率是它为了处理异常和资源释放硬凑的，拆开看其实没那么玄。

中文分块确实挺头疼的，我最近也在折腾类似的东西。你试的256和512对中文来说其实偏小了，中文一个字的信息密度比英文单词高不少，512 token对中文可能就三四百字，长一点的条款肯定被腰斩。我后来换成按标点做递归分割，separators设成["\n\n", "\n", "。", "！", "？", "；", "，"]这种顺序，优先在段落和句号处切，效果比纯按长度好很多。不过说实话，光调sepa

few-shot确实管用，给两个带try和超时的例子它就老实了，另外让它输出前自己跑一遍异常场景测试。 我试过把“自查”写进prompt，让它模拟输入和断网场景跑逻辑，比单纯review省心不少。

loss平台期挺正常的，代码补全这种任务1.2已经不错了，效果能打比数字好看更重要。要不试试调低rank看泛化有没有变化？

说实话你这个问题太真实了，我搭Agent也遇到过类似卡壳，后来发现核心不是上不上LangGraph，而是先得把“状态机”思维刻脑子里——每个节点明确能做什么、不能做什么，比让模型自由发挥靠谱多了。你试试把用户意图拆成几个固定子任务，手动写死跳转逻辑，哪怕丑点，至少能跑通再谈优化。至于框架，等手动流程稳定了再迁移不迟，不然换个壳问题照样在。

之前跑多卡DDP也遇到过类似情况，后来发现是梯度累积和同步的交互问题——如果用了梯度累积，要确保只在累积到指定步数后才做all-reduce，否则梯度会部分更新导致震荡。另外LoRA的rank如果设得比较小，分布式下不同卡上的低秩矩阵初始化差异会被放大，可以试试固定种子并检查一下每卡初始化是否一致。还有个小点：你确认一下DDP里用的是不是同一个学习率调度器实例，有些写法会让每张卡各自调度，步数错位

我试过类似组合，量化到INT4确实能明显压显存，但要注意精度损失对生成质量的影响，尤其是长文本场景。流水线并行的话，单卡上开反而可能增加通信开销，不如先试试把KV cache换成FP8，或者调整--gpu-memory-utilization到0.9看看。你8并发是不是还开了前缀缓存？那个有时候会偷偷吃不少显存。

我之前也是两头折腾，最后选了LlamaIndex做数据层的索引和检索，LangChain只用来管agent和memory。其实两者不是非要二选一，关键是你把文档预处理和查询质量这块放心交给LlamaIndex，LangChain的对话逻辑本身也不需要太依赖它的检索能力，这样各干各的反而顺手。不过你后续要加工具调用的话，得注意一下两个框架的callback和链式调用会不会互相干扰，我当初就是在这里调

说实话你这个问题我太有共鸣了，之前调chunk size也调到头秃。后来发现个关键点：别只看chunk size，得看你文档的结构和检索粒度是不是匹配。技术文档里Markdown标题层级本身就是天然的分块边界，按标题语义切比死磕数字靠谱得多，比如先按二级标题切，再对超长块二次分割。overlap我个人觉得10%真的够了，但前提是你要保证切出来的边界不在代码块或表格中间，否则设多少都没用。至于代码和

这问题我踩过类似的坑。LLM做rerank跟生成任务是两码事，你拿几百条数据微调，模型大概率只记住了排序的表面模式，但没学会真正理解query和文档的深层相关性，loss降了往往是过拟合到训练集了。另外，你训练时的负样本是怎么采的？如果全是随机负例，模型根本没见过那些高相似度的干扰项，线上遇到bm25都排前面的难分样本自然就懵了。建议试试用bm25和embedding的混合结果做难负样本挖掘，或者

说实话你这个配置看着没啥大毛病，rank16对7B模型不算高，lr2e-4也是LoRA常见区间。但loss卡在1.8下不去，我第一反应是数据问题——5000条客服对话里如果意图分布特别散，或者每轮对话长度差异巨大，模型很容易学个大概就摆烂。你可以先看看训练集和验证集的loss差距，如果验证集从一开始就高不少，那八成是数据里有噪声或者标注不一致，模型在硬记那些冲突样本。 另外你提到回答重复和答非所

说实话你这个配置跑起来不该这么痛苦，500 tokens对8B模型不算长，问题大概率出在rank=32上，客服场景其实8-16就够用了。另外gradient accumulation设4步loss抖是正常的，建议把学习率降到2e-4左右，同时开bf16和gradient checkpointing，batch size=2配8步累积更稳。你可以试试先拿2000条数据跑个小实验调参，确认loss能平

说实话你这个情况我太懂了，之前搭内部知识库的时候也被这个问题折磨过。chunk_size和overlap只是最基础的参数，但PDF里那种长表格或者碎段落，固定500字去切很容易把语义边界切碎，比如报销流程和差旅标准如果出现在同一页表格的相邻行，检索时向量距离自然就近了。我倒觉得不一定是embedding模型的锅，OpenAI那个ada-002对长文档和表格结构其实挺钝的，你可以试试先做段落级别的结

遇到过一样的坑，top-k拉满看似全面，其实把噪声也带进来了。后来我加了重排序这一步，用cross-encoder对召回文本再打分，只留前3-5条最相关的，效果立马干净很多。 另外你还可以试试调低chunk的大小，或者对召回文本做个简单的关键词去重，那些只靠词面匹配的段落很容易被过滤掉。生成的矛盾问题，多半是上下文里塞了太多立场不一致的片段，数量砍半后基本就消失了。 还有一个偏门但管用的操作：

我之前也踩过一模一样的坑，loss看着正常但生成全是乱码，最后发现是prompt里少了ChatML模板那几个特殊token。你如果用的官方chat模型，推理时得手动加上`<|im_start|>`和`<|im_end|>`，不然模型完全不知道在干啥。另外可以试试把学习率降到1e-4以下，LoRA的alpha调小点，有时候是微调过头导致灾难性遗忘。还有个小技巧，先用你训练数据里的一条原始文本直接喂给

确实，协同算法才是真正的护城河，规模只是表象。之前看国外团队做百架级表演还得靠预编程，国内直接上千架实时动态调整，这种对延迟和容错的处理能力差距不是一星半点。 不过有个疑问想请教下，复杂电磁环境下这种亚米级同步具体怎么保证的？是靠双频RTK加惯导融合，还是说通信层有特殊的抗干扰机制？之前做项目时我们一遇到信号遮挡就容易漂移。 另外你说到“一控多机”架构，我理解是地面站做全局规划、机载做局部避障

说实话我觉得你现在这个阶段上代理池有点早，核心问题不在IP而在请求特征上。requests的TLS指纹太明显了，就算换了UA和延时，服务器那边一眼就能认出你不是浏览器。我建议你先试试curl_cffi这个库，它模拟浏览器指纹比requests强很多，有时候光换这个就能解决一半问题。至于Selenium，我不太推荐你现在就切过去，爬虫逻辑全改不说，内存占用和速度都是硬伤，反爬强的站点照样能检测web

说实话我觉得这跟MCP关系不大，核心还是看你模型本身怎么训练和导出的。PyTorch用TorchServe或者自己写个FastAPI包装一下，接MCP完全没问题，TensorFlow案例多可能只是历史原因。我自己的经验是，PyTorch的动态图在调试推理接口时更顺手，尤其是遇到输入shape不对或者自定义op的时候，报错信息直观得多。 另外你如果只是封装推理，其实框架影响更小，反而是序列化和服务