周末安全手记
Lv.1主要整理信息安全相关的学习笔记与工程经验，内容覆盖攻防案例复盘、安全测试与风险分析。希望内容既讲清为什么，也说明怎么做，希望把复杂问题讲清楚、把实践步骤写完整。
发表的评论
这个我深有体会，Cline默认就是整文件diff，你得在prompt里明确说“只输出需要修改的那几行，用search/replace格式”，不然它图省事直接重写。我一般会在项目根目录放个.clinerules，写清楚“改样式时禁止重写组件逻辑”，效果还行。不过说实话Cursor的inline edit确实更顺手，选中那段className直接cmd+k改，不会动其他地方。Windsurf我没深度用
合同这种条款型文档按固定字数切肯定断，试试按段落或标题切，重叠只保边界就够了。
10个epoch太多了，过拟合严重，试试减到2-3个epoch，学习率降到5e-5看看。
刚入门，这个对我帮助很大。
学到了，感谢分享！
这个思路不错，收藏了。
有没有更详细的教程推荐？
几千个chunk其实不算大，rerank模型选个轻量级的，比如bge-reranker-base，延迟也就几十毫秒，线上基本扛得住，比你在prompt上反复调要靠谱得多。另外top5召回里混进擦边内容，很多时候是embedding本身区分度不够，可以先看看召回结果的分数分布，如果top1和top5分差很小，说明检索阶段就没拉开差距，这时候光靠rerank也救不了。我的做法是先用rerank筛到to
V100 16G跑GPTQ-4bit的7B理论上够，但你崩多半是KV cache没管住。vLLM开gpu_memory_utilization=0.9加enable_prefix_caching会稳不少，比裸transformers强太多。真要保险就换AWQ，4bit下比GPTQ省一点显存，配合vLLM基本能压住长上下文。还不行就上GGUF走llama.cpp，CPU+GPU混合offload，速
我之前也踩过这个坑，纯BM25在中文场景下确实很容易被高频词带偏，“苹果”这种多义词基本无解，因为BM25只看词频和逆文档频率，压根不关心上下文。你说的分词器消歧其实指望不上，主流分词器只是切词，顶多做个词性标注，真要做词义消歧那是另一套NLP任务了，成本不低。轻量点的办法可以先试试给查询加个领域词典或者实体识别，比如识别出“苹果手机”就把它当成一个整体term，而不是切成“苹果”和“手机”，这样
固定长度切就是容易这样，试试按标题或段落切，再加个rerank模型效果会好很多。
A10跑7B AWQ这个速度确实偏慢，但也不算完全离谱，关键得看你的具体配置。15-20 tokens/s在并发8的情况下，如果每个请求都在同时生成，那总吞吐其实是120-160 tokens/s，这个数字放在A10上不算太差，但首token 3秒多确实有点问题。你检查过max_model_len吗？如果设得太大，比如8192甚至更高，KV cache会占掉大量显存，导致实际能用的batch si
检索准不代表生成就能用，这俩其实是两回事。top5相关但答案泛，大概率是LLM没被约束到那些细节规范上，光靠embedding调解决不了。我之前试过一边LoRA生成模型一边加few-shot示例，效果比只调检索侧明显得多，尤其行业标准这种术语密集的场景。不过few-shot得挑真正体现规则的关键片段，不然容易带偏。你先试试在prompt里塞两三个精准示例，成本低还能快速验证是不是LLM理解的问题。
8G显存跑8B的Q4确实挺紧张的，ollama默认可能没完全offload到CPU，你可以试试在Modelfile里调num_gpu层数，留一两层给显卡就行，剩下的扔CPU跑。llama.cpp那边用-ngl参数控制，别全塞显存里，速度慢可能就是因为爆了之后偷偷走CPU了。RAG实验的话其实7B的Q4_K_M更划算，或者试试Q3_K_S，显存压力小很多，精度掉得也不算太狠。swap就别折腾了，那玩
我也有这感觉，尤其是写模板代码的时候，Tab按得根本停不下来。但后来发现，越是依赖它补全，遇到它搞不定的问题就越容易卡住，因为脑子已经习惯被动等答案了。我现在刻意在写核心逻辑前先自己理一遍思路，哪怕最后用它的建议，至少心里有数。这东西当加速器可以，别让它替你思考就行。
这个问题我太有共鸣了，之前用LangChain做类似的东西也踩过一模一样的坑。工具明明返回了正确的JSON，Agent却一本正经地说“调用失败”，然后换个参数再来一遍，看着日志真的血压高。后来我发现很大一部分锅不在工具本身，而是Agent对“成功”的定义太模糊了——它很多时候是在靠语义猜结果对不对，而不是靠明确的字段判断。你可以在工具返回里加一个固定的status或者success字段，再在pro
小模型做二分类比LLM靠谱多了，bge-reranker这类拿去微调一下，比死磕prompt稳。
短期记忆这块我也踩过类似坑，后来干脆把向量库只当兜底，最近几轮直接按时间顺序全塞进去，反而更稳。你那个“那明天呢”的问题本质是 query 太短、语义漂移，检索自然会把上一轮天气原样捞回来。我的做法是先做一轮滑窗截断，再用 rerank 把重复度高的片段压掉，效果比单纯限 topk 好不少。
RASP这块我踩过坑，规则维护确实是个无底洞。去年我们上了某家的RASP，光是给核心交易链路做白名单就折腾了两个月，业务迭代一快，规则立马跟不上。所以长亭想用AI来降低规则依赖这个方向我是认的，但问题在于RASP的误报代价太大了，直接拦请求啊，不是WAF那种记录一下就行。AI模型再准，只要在生产环境误杀一笔订单，业务方就能把你喷到怀疑人生。我比较好奇的是他们怎么处理AI决策和RASP阻断之间的置信
500字符切PDF太碎了，先试试按标题层级切，再上混合检索加rerank，召回能明显好一截。