北岸修行记
Lv.1在山海与代码之间保持好奇，关注技术学习与数字生活，记录知识体系搭建、项目实践记录和真实实践中的思考；不追求堆砌概念，只记录验证过的经验。保持好奇，保持实践，也保持独立判断。
发表的评论
Agent场景下延迟比模型尺寸重要多了，多轮交互等两三秒真的没法忍。我之前用Qwen2.5-7B搭llama.cpp跑，4bit量化加KV cache优化，单轮能压到一秒内，工具调用够用了。vLLM对AWQ支持其实还行，你可以试试AWQ量化配vLLM，比GPTQ稳一些。长上下文对规划影响挺大的，上下文一长模型容易丢前面的工具返回结果，建议控制在8k以内别硬拉。
这个思路不错，收藏了。
你这情况太典型了，我前阵子也踩过一样的坑。后来发现光靠prompt讲原则基本没用，得在项目里放一份具体的代码风格示例文件，让它参考着写，效果会好很多。另外别指望它一次生成整个模块，我都是一段一段来，写完一个函数就review一下顺手拆好，不然后面积累起来真的改不动。至于复杂业务逻辑，感觉还是得自己搭骨架，AI填填CRUD和工具函数比较靠谱。
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
有没有更详细的教程推荐？
我们线上大概三千万切片，ES的KNN确实在高并发下会抖，尤其你还要同时跑BM25和向量，内存和延迟都得盯紧。几百万级别其实可以先ES扛着，但把向量索引单独拆到Qdrant或Milvus，用ES只做关键词召回，成本没高多少。Rerank别一上来就全量上，先拿几百条badcase跑个交叉编码器看看提升，不行再决定。
代码审查这事我也折腾过一阵，后来发现把“逐行分析”去掉反而稳了，因为模型一旦被要求逐行就容易凑字数硬挑毛病。我的做法是拆成两步：先让它只输出最严重的三个问题，不带解释；确认没问题后再单独追问某一处的细节。给正反例确实有用，但例子别太多，两三个就够了，多了它反而会往例子上硬套。你说的系统1加系统2，其实就是先扫后审，这个思路靠谱，我自己也是这么跑的。
先别急着换embedding，你这情况八成是chunk把条款切碎了，违约金的关键句可能刚好被拦腰截断，检索出来自然对不上。建议按合同条款结构切，别死磕固定长度，同时把query和chunk都做一下关键词增强试试。另外rerank确实值得加，召回先放宽再精排，比直接换贵模型见效快。text-embedding-3-large提升有但没你想的那么神，先把切分和rerank理顺再说。
几十万到百万级这个量级，说实话两个都能扛住，关键还是看你团队愿意花多少精力在运维上。Milvus单机那套etcd加MinIO确实劝退小服务器，我当初也是被这个劝退的，后来换Qdrant单二进制跑起来是真舒服，内存占用也友好不少。你们偶尔要按部门过滤，Qdrant的payload索引做filtered search挺顺手的，这块体验比想象中好。不过生态这块得承认Milvus更热闹，文档、中文社区、各
你这个“思考链+最终结论”的结构确实吃token，300行代码一进去，历史对话再一叠，不爆才怪。我一般会先把代码按函数切块，只把相关片段喂进去，别整文件硬塞。另外MCP这边可以试试在工具层做摘要压缩，把旧轮次的结论压成短句再回传，比在Prompt里写“忽略历史”靠谱多了。还有个坑是结构化输出本身会占很多位置，能精简的字段尽量别留。
2万条数据做客服其实不算少，但关键在于对话的“质量”和“一致性”。你描述的这种时好时坏，八成是数据里本身就有矛盾——同一个商品，不同客服话术不一致，模型就学岔了。LoRA的rank和alpha也值得看看，如果rank太低（比如8），模型对细节的记忆能力会很弱，商品信息这种需要精准复现的内容就容易飘。另外你有没有加system prompt来约束身份和边界？Llama3本身中文能力就一般，不加约束很
loss低不代表生成对，八成是训练格式和推理prompt不一致，模型没学会啥时候停。
我最近也踩过这个坑，长Prompt真的不一定更好。我的经验是把任务拆开，先只锁定字段和格式，示例给一两个就够，背景介绍反而容易让模型分心。用XML标签分隔指令和输入确实会稳一些，但太长的话模型还是容易漏字段。你可以试试把1000字压到300字以内，只留最关键约束，效果可能比加结构更直接。
我们生产环境用的Qdrant，单节点跑千万级向量还挺稳的，但集群模式文档确实有点跟不上，踩过几次分片配置的坑。Milvus功能更全，不过那套依赖etcd和MinIO的架构对小团队来说运维成本偏高。你们数据量大概什么级别？如果没到亿级，其实Qdrant单机加好点的SSD就够用了，别一上来就上分布式。
你这情况八成是召回阶段就偏了，光调阈值和chunk大小治标不治本。建议先加个query改写，把用户口语化的问题转成更贴近文档表述的检索词，效果提升挺明显的。rerank强烈推荐试试bge-reranker-large，跟你的BGE embedding是同系列，配起来省心，基本能把无关片段压下去。另外chunk别只盯大小，可以试试按语义或标题切，保留点上下文重叠，召回质量会稳很多。
几十万数据Qdrant单机够用了，过滤检索也快，内存比Milvus省不少，小团队别折腾集群。
小batch场景下编译收益确实很有限，你这情况挺典型的。torch.compile最吃香的是大batch、固定shape、反复跑同一张图那种推理serving，微调这种每步都可能有梯度累积和优化器状态变化的反而容易被overhead吃掉。你padding到512但attention mask是不是还是变长的？mask形状一变就可能触发recompile，可以打个torch._dynamo.expl