一线安全随想

同感，我用Copilot半年后也有这种“手生”的感觉，尤其是写一些基础算法时第一反应是等提示而不是自己推。后来我刻意每周抽半小时关掉补全手写点小逻辑，不求快，就当作脑力热身，慢慢手感回来了。至于维护，AI写的代码最坑的是风格和边界处理不统一，建议生成后自己过一遍，至少加上注释说明意图，不然过俩月谁看都懵。刷题倒不一定必要，但读读自己项目的核心模块源码确实有用。

几十万条全量算余弦其实还好，numpy或者faiss的flat模式都能扛，真正难受的是并发一上来CPU直接打满，延迟抖动特别大。我自己测过一百万条768维的，flat大概200ms左右，HNSW能压到个位数毫秒，但召回率会掉几个点，调efSearch能补回来，代价是延迟又上去。瓶颈其实两边都有，暴力检索是延迟和吞吐，HNSW是召回和内存，IVF则是训练和nprobe调参比较烦。过滤条件这块确实是个

十几万条768维够用了，降维省不了多少内存反而丢召回，增量更新Milvus比faiss省心。

模板化数据太多，模型学会偷懒复读了，先把那些重复回复筛掉再训。

几百万数据pgvector够用了，省得再维护一套，HNSW的m和efConstruction多试几组就有感觉了。

2万条数据跑3个epoch确实有点猛，loss降太快反而容易过拟合到表面模式，参数类型这种硬约束它根本没学扎实。我建议先把epoch降到1，然后在训练数据里加一些故意写错参数格式的负样本，让模型学会区分对错。另外Qwen2.5-7B做工具调用本身够用，但MCP这种结构化输出最好配合constrained decoding，光靠prompt和微调很难保证100%不出错。

我觉得切块真不能一刀切，得看你的问题类型。产品手册这种，用户问的往往是某个功能怎么操作，按章节或语义段落切比死磕token数靠谱多了。500token加overlap其实挺容易把一条完整说明拦腰截断，检索出来自然答非所问。可以试试先按标题层级切，再做小块，检索时把相邻块一起召回补上下文。评估的话别只看命中率，重点看召回的内容能不能独立支撑答案。

先别急着上重排，切分时把标题和上下文拼进chunk里试试，很多时候是这块丢信息了。

1亿条768维单机跑确实够呛，你这数据量已经不是调参能救的了。建议先确认下是不是memory-mapped模式没开，SSD随机读和内存映射的差距在亿级数据上会被放大得很明显。另外别纠结HNSW还是IVF了，这规模优先考虑分片吧，哪怕按ID哈希拆成4个collection都比单机上硬扛强，召回压力直接摊薄。GPU对召回延迟提升有限，除非你瓶颈真在暴力计算上，但看描述更像索引结构和内存带宽的问题。可以

我最近也在折腾Qwen2.5-Coder，7B确实有这毛病，尤其是生成带嵌套逻辑的代码时，一旦函数体超过二十行就容易断，而且断点特别随机，有时候连return都没写就停了。后来我换了个思路，把vLLM的采样参数里repetition_penalty调到了1.15，稍微好一点，但治标不治本。我个人感觉7B的注意力窗口在长代码生成上确实有物理极限，它对“接下来要写什么”的全局规划能力不够强，更像是局部

我觉着大概率不是模型能力问题，Qwen2.5-7B的tool calling底子是够的，你loss降到0.8看着挺正常，但3000条LoRA数据对远程API这种动态格式来说可能太少了，尤其Jira这种返回结构复杂的。我之前调类似场景时发现，模型容易把样例里的参数名死记硬背，一旦真实请求字段顺序或嵌套变一下就懵了，建议你重点检查微调数据里有没有覆盖各种边界情况，比如空值、多级嵌套、枚举值。另外你sy

说实话我觉得你这个问题大概率不是换embedding能解决的，bge-large-zh对中文实体已经挺敏感了，但embedding本质是语义匹配，它天生就会把“截止日期”这种具体数值和上下文背景混在一起。你调chunk_size没用也正常，因为核心问题在于检索粒度——top-3片段如果是整段话，即使里面包含了日期，也可能被其他更“像问题”的句子挤掉排名。我之前遇到过类似的，后来是加了一层基于正则或

2万条数据跑3个epoch，loss到0.8其实不算低，我怀疑你那个中英混杂的数据集确实是主要问题，LoRA参数倒是其次。我之前试过类似情况，把数据里英文部分全过滤掉，或者单独加5%的中文通用语料做回放，效果能明显改善。另外rank=8对8B模型来说偏小，你可以试试rank=16或32，alpha跟着翻倍，但记得把学习率降到1e-4左右，不然容易训飞。最后建议你拿原版base和微调后的模型跑同一批

固定长度切分对技术文档确实容易翻车，代码和表格的边界跟token数根本不对齐。我现在生产环境用的是先按Markdown标题和代码块做结构切分，再对长段落递归切，overlap控制在100-150左右，效果比纯固定好很多。rerank的话建议chunk别太大，400-600tokens配top20召回再重排，比一开始就掐top5稳。另外你试试把流程图描述文本单独抽出来做索引，不然图片上下文很容易污染

我最近也踩过这个坑，后来把few-shot砍到只剩1个最典型的例子，长格式要求全塞进一个压缩过的输出规范里，系统prompt只留核心角色设定，体感能省出30%左右的token。另外你可以试试把模板拆成“静态骨架”和“动态注入块”，MCP的变量注入其实更适合传数据，不适合传大段指令。还有个偏方，如果上下文快爆了，可以手动把前面的对话摘要成一小段再继续，虽然麻烦点但比硬撑强。

兼容ROCm确实聪明，之前搞过几款国产卡，最烦的就是要重新适配算子，项目周期直接翻倍。海光这一手等于把迁移成本打下来了，开发者自然愿意试。 不过就像帖子里担心的，如果只做“兼容”而没有自己的优化空间，比如针对某些垂直场景的深度调优，那跟直接用英伟达的卡加个转译层有啥区别？差异化不能光靠生态，还得看能不能在软硬协同上拿出点独家的东西来。 浦东政府愿意站台，说明政策风向是真的变了，但最终能不能跑出

8G显存跑7B其实挺极限的，我试过3070上跑Qwen2.5-7B的int4量化版，llama.cpp加offload到CPU能跑，但速度感人，大概也就5-8 token/s，当内部测试勉强能用。不过你这场景是知识库问答，如果文档不多，建议试试小一点的模型比如Qwen2.5-3B，响应快很多，或者干脆用RAG把检索和生成拆开，这样显存压力小不少。另外提醒下，8G跑int4虽然能加载，但上下文一长就

说实话我觉得问题大概率出在切分策略上，512字符对中文技术文档来说太长了，尤其是操作步骤类内容，经常把“配置文件路径”和“修改端口的命令”硬塞进同一个chunk，语义密度被拉低，检索时自然分不清主次。你可以试试按段落或者语义边界切，比如用句号、冒号、换行做分割点，chunk控制在200-300字符，overlap可以降到32，这样每个片段主题更聚焦。另外bge-large-zh对短文本的区分度其实

我一般会在prompt里直接塞一句“没找到就直说不知道”，比单强调“基于文档”管用，你试试。

先别急着上框架，手动把状态机和回退逻辑跑通，你会对Agent的边界理解得更深。 框架只是工具，真正难的是你给Agent定义的决策边界和恢复策略。