实战派NLP工程手记

我现在基本把AI当“写第一版草稿”的角色，不会让它直接定稿。你提到的并发和异常路径，恰恰是它最容易糊弄过去的地方，因为训练数据里这类代码本身就少，而且它倾向于给你一个能跑通happy path的版本。我的做法是先把接口和状态机自己画清楚，再让AI往里填实现，这样它自由发挥的空间小了，低级错误也少很多。prompt上我会明确要求它列出所有可能的异常分支和边界条件，并且强制它写对应的单元测试，虽然它写

苹果种植那个例子太真实了，我也踩过这坑。你可以试试在Prompt里直接让模型先给每段打分再挑，比如“按相关性1-5分打分，只保留4分以上的段落来回答”，实测比单纯调阈值灵活不少。另外加个Cross-Encoder重排也就几行代码，LangChain里有现成的，能明显把种植技术那种挤下去。deadline紧的话先上重排，性价比最高。

固定字符切块确实容易把语义切碎，产品手册这种结构化文档更适合按标题段落切。先试试语义切块吧，重排模型可以后面再加。

短文本可以拼上前后文一起embed，领域微调效果提升挺明显的，值得试试。

先别急着换模型，实体漏召回八成是纯向量检索的锅，加个BM25混合召回再重排试试。

这问题太真实了，我前阵子用Cursor搞RAG的tool calling也被坑得不轻。它编参数还算小事，最要命的是把函数名和参数结构“脑补”成看起来合理但实际不存在的版本，然后你让它自查，它还能给你圆回来，因为训练数据里相似接口太多了。我的经验是别指望把整份文档塞进上下文就能解决，长上下文里模型对中间部分的注意力会衰减，越到后面越容易放飞。后来我改成把每个工具的调用签名、必填字段、示例请求单独写成

我也踩过这个坑，后来发现chunk大小真不能拍脑袋定。技术手册这种结构化强的文档，512配10%到15%的overlap比较稳，切的时候尽量按标题或段落边界走，别硬按字符数切。你那1024混进无关内容，大概率是切点落在了不相关段落中间。可以试试LangChain的RecursiveCharacterTextSplitter，再加个rerank模型过滤一下，效果会好不少。

你这情况太常见了，我当初也纠结过一阵。实际用下来感觉还是看场景，做研究发论文PyTorch确实顺手，动态图调试起来舒服很多。但真要上生产，TF的SavedModel和TFX那套工具链在服务端部署确实省心，尤其团队协作时接口规范统一。建议你先别急着站队，两个都摸一遍，反正核心概念是通的，转起来也就一两天的事。

loss卡在2.3左右、准确率跟瞎猜差不多，这症状太像模型根本没在学东西了。你检查的那些超参其实都还好，问题大概率出在更基础的地方。我之前也踩过类似的坑，最后发现是[CLS]那个位置的用法有问题——你是不是直接取了序列第一个token的输出？如果padding加在前面或者position encoding实现有偏差，那个位置可能根本学不到全局信息。建议先别急着调参，拿个极小的子集（比如几百条）跑一

这种代码库级别的迁移，光靠系统提示确实很难压住它自由发挥。我一般会把大重构拆成小任务，每次只让它改一个配置类，改完先跑测试再继续，不然它一兴奋就顺手重构一大片。另外可以在Agent里加个“不确定就停下来问”的硬性检查点，比如让它输出改动前先列个疑问清单，比单纯说“严格遵循风格”管用。工具本身倒不是主要问题，Claude做这类迁移够用了，关键是工作流得收着点。

32K上下文和真正能稳定利用32K是两回事，尤其你还上了GPTQ 4bit量化，权重精度损失对长距离依赖的伤害其实挺明显的，变量名、import这种细节最容易在量化后被“模糊”掉。我自己用Qwen2.5-Coder 7B的GPTQ跑过类似任务，500行类重构到一半开始编造字段名是家常便饭，后来换成AWQ或者干脆用fp16跑，同样提示词下稳定性肉眼可见地好一些，当然显存代价也上去了。你提到RAG，我

说实话你这个问题我太有共鸣了，之前调RAG也是这么过来的。先别急着怀疑embedding，ada-002对语义泛化其实够用了，问题大概率出在chunk和文档结构上——产品手册里经常有“参数表”和“流程说明”混排，你按固定size切分，很容易把“售后服务”那几行字跟隔壁的“保修条款”硬凑成一坨，召回的自然全是参数了。我的经验是，先别用sentence splitter，试着用PDF的标题层级做结构化

你这情况我也踩过坑，问题八成出在分块和query意图的错位上。“打印机卡纸”这种故障类问题，关键词本身信息密度极高，而512token的段落会把很多无关上下文卷进向量里，反而稀释了核心语义。建议试试把分块缩小到128-256token，或者干脆按句子切，再配合BM25做混合检索，用RRF融合排序，效果一般会立竿见影。另外text-embedding-3-small对中文专有名词和短指令确实偏弱，有

7B这个量级直接上FSDP吧，省显存还能顺手调大batch，DDP留给更小的模型更省心。

几十万篇这量级确实卡在Chroma的尴尬区了，本地demo和线上并发完全两码事。我当时也被Milvus那套依赖吓住，后来直接上了云厂商的托管向量库，省心太多。你如果不想折腾部署，先看下Qdrant的docker compose，单机模式比Milvus轻不少，过滤性能也稳。选型我个人觉得别光看量，还得看你要不要复杂过滤和混合检索，否则pgvector+索引调优也能扛一阵，但长期扩展肯定要换专用库。

同感，我之前做客服bot也这样，提示词写再长，用户一换口语化问法就破功。后来发现800字系统提示词可能反而限制太死，模型容易在“套模板”和“自由发挥”之间摇摆。 你试过把few-shot例子精简到2个以内，同时明确告诉模型“用户问法可能不标准，先理解意图再组织语言”吗？我这么改之后稳定性明显好了，而且“作为一个AI”这种话得单独加一条硬性禁止规则，光靠语气规范压不住。 另外检查下是不是历史对话

说实话你这问题我太有同感了，512字符切出来就是典型的“只见树木不见森林”，尤其技术文档里接口和依赖经常散落在不同章节，你就算用sliding window把前后文拼回来，检索阶段还是容易抓错重点。我后来试了按文档结构切，比如先按标题分块，再把每个标题下的段落作为一个整体，chunk size直接看内容长度，不硬性设死，效果比固定数字靠谱很多。另外rerank确实是玄学，但我觉得关键不在模型，而在

这问题太真实了，我刚开始用的时候也差点被整崩溃。后来发现光在prompt里喊口号没用，得把规矩拆碎了喂给它，比如直接贴一段你项目里写得规范的老代码当few-shot示例，它模仿能力其实很强。另外我试过把eslint的react-hooks规则文件路径直接丢进prompt里，让它先读再写，效果比单纯说“遵循规则”好不少。上下文长度确实是个坑，它记不住太早的指令，所以我现在都是把关键约束重复放在每个新

试试给每条记忆加时间戳和意图标签，检索时先按标签粗筛再按向量精排，比单调阈值靠谱多了。

温度这块我建议直接拉低到0，格式问题靠采样参数基本没救，写代码注释这种任务随机性就是敌人。few-shot示例宁可少而精，别给那种函数体很长的例子，模型会模仿代码风格而不是约束本身。你试试把输出框架钉死，比如让它在代码块里先写函数名再写docstring，结构上不给它自由发挥的缝隙。另外可以加一步后处理校验，用AST解析检查输出里有没有非法语句，比反复改prompt省心多了。