稳步前行机器学习成长记

70B本地跑代码辅助确实有点吃力，双4090上vLLM能提速但显存还是紧，建议试试张量并行加4bit AWQ，速度会好不少。量化掉质量这个基本无解，代码任务对精度太敏感了，要不就换34B或者Qwen2.5-Coder-32B，体验反而更稳。TensorRT-LLM配置确实坑多，可以先拿vLLM跑通再考虑换。真想省心就API吧，本地折腾性价比太低了。

混点通用数据进去会好很多，5k条全垂直太容易过拟合了。

gpt-3.5工具调用本来就容易翻车，换gpt-4o-mini试试，便宜还稳不少。

分层输出确实刚需，改稿能省一半时间，但国潮纹样识别率真有那么高吗？

这个评测挺有意思，我们组之前做商场导视识别也踩过类似的坑。高跟鞋烟斗这种抽象符号确实考验模型的语义映射能力，但我觉得86分和78分的差距可能没看起来那么大，样本量小的话波动很正常。推理模式“想太多”这个点我也有同感，有时候简单场景反而容易翻车。不过Kimi才38分属实有点意外，是测试集偏门还是模型本身视觉编码弱？

1亿条768维单机确实有点顶了，召回掉到1秒大概率是内存装不下全量索引，SSD再快也扛不住频繁换入换出。HNSW内存占用比IVF大不少，但召回率和延迟更稳，你这种情况可以先把nlist调大、nprobe压低试试，同时看看有没有开mmap。说实话单机到这个量级，分片或者换GPU版基本是迟早的事，光调参救不了。

50万条但格式太杂了吧，建议先拿几千条高质量的去重数据试试，r=8可能真不够。

3090跑13B确实吃力，量化掉质量基本是必然的。我建议你试试AWQ的4bit，比GPTQ对代码任务友好一些，再配合vLLM的paged attention，长文本会稳很多。其实日常写代码查资料，7B微调好的模型未必比13B量化差，比如DeepSeek-Coder-7B就很能打。别死磕13B了，省下的显存留给上下文更实用。

loss降到1.2还这样，感觉更像是SFT数据里混了太多解释性文本，模型把“先分析再给标签”当成模板学走了。你可以先检查下训练样本里有没有类似“根据描述……”这种前缀，有的话清掉重训。另外学习率如果偏大，确实容易让格式崩，QLoRA一般2e-4以内比较稳，轮数也别贪多。想让输出严格JSON，除了解码约束，更推荐在数据里统一塞一个固定前缀再配schema，训练时就让模型只学这个格式，比硬卡稳不少。

我其实觉得这个问题不全是Prompt的问题，而是我们对“明确”的理解有偏差。你说“批量读取CSV并算平均值”，在你脑子里可能默认了“只做这件事，别加戏”，但模型看到的是一堆可能的实现路径，它选了一条自己觉得“更负责”的路，比如帮你处理异常值。这不是它不听话，是它在补全你没说出口的上下文。我一般会在指令里加一句“只做我要求的事，不要添加额外逻辑或注释，除非我明确问你要”，效果挺明显的。另外就是把任务

这种情况挺常见的，别慌。两千条数据对LoRA来说其实不算多，尤其如果数据质量参差不齐或者格式不统一，模型很容易学到一些奇怪的模式，反而把原来基座模型的能力带偏了。你loss降得正常不代表泛化好，可能只是过拟合了训练集那点分布。另一个容易被忽略的点是，推理时的prompt模板得跟训练时严格对齐，包括特殊token、system prompt这些，差一点模型输出就会崩。我建议你先拿训练集里的样本去推理

官方的稳但功能少，社区的挑star多、最近还在更新的试，代码分析建议先跑官方文件系统那个。

PDF技术手册切512其实偏小了，表格和跨页段落很容易被切碎，召回不稳多半是这个原因。建议试试按标题层级切，或者用semantic chunking，再配合bge-reranker-v2-m3做精排，top20粗召回后重排效果会稳不少。BM25对中文技术文档帮助有限，不如先解决切块语义完整性的问题。

温度设0只是选最可能的词，重复输出多半是没加重复惩罚，试试repetition_penalty调到1.1。

几十万条记录其实不算大，768维配个好点的模型（比如bge-m3）完全够用，别盲目追高维。我实际跑下来，1536降到768对召回影响很小，但延迟和内存直接砍半，性价比很高。量化到128维那种就有点狠了，语义损失会比较明显，除非你做的是粗筛场景。建议先用768跑个基线，拿真实query测下recall@10，再决定要不要往上加。

GPT-2的inputs_embeds和token_type应该没问题，重点查下past_key_values是不是把梯度截断了，调优时得关掉cache。

7B模型确实对prompt比较敏感，我拿Qwen2.5-7B和14B都试过，同样一句话，14B稳得多，小模型就容易飘。你可以试试把任务拆成两步：先让它列个函数签名和依赖，确认后再让它补全实现，比一次性要完整代码靠谱。另外温度调低一点，0.2左右对写代码帮助挺大。还有个歪招，在prompt里塞一句“以下是能直接运行的完整代码”，它反而更容易认真写全。

这问题太真实了，我也经历过这个阶段。我的做法是让AI先写一版，然后自己重构成能看懂的样子，重点是让它解释每段逻辑而不是照单全收。prompt里可以直接说“用同步写法”“别用元类”“像给新手写的一样”，效果还行。硬读AI代码不是不行，但前提是你得先有判断力，不然就是被它牵着走。

这个坑我踩过，问题多半不在embedding，而是纯向量检索没有时间维度。text2vec-base-chinese本身还行，但512字切分把上下文切碎了，语义容易漂。可以试试混合检索，Qdrant支持payload过滤，加个时间范围先筛再召回，或者给score乘个时间衰减系数。另外查“上周那个项目”这种指代性query，最好先让LLM改写一下再检索，不然embedding根本抓不到重点。

这个问题太真实了，我上个月刚被类似的东西折磨过一轮。我的体感是，多步工具调用断链基本是通病，跟LangChain写法关系没那么大，核心还是模型在多轮里对“已获得的信息”保持不住。你描述的第二类错误，工具返回结果一复杂就幻觉，我遇到的最多，本质上是模型看到一坨嵌套JSON之后，宁可自己编一个看起来对的结构，也不愿意老实去解析。调temperature和加few-shot只能缓解，因为这不是采样随机性