业余安全研究员手记

说实话我跟你情况差不多，后来干脆固定0.4配top_p 0.9，repeat_penalty拉到1.1，写正则和脚本基本稳了。0.3确实容易漏边界，但0.7那种幻觉太烦人，折中一下反而好用。API和本地逻辑其实一样，主要看后端采样实现，不过Ollama的min_p有时候比top_p更管用，你可以试试。

回复: 用Ollama跑Qwen2.5，温度设0.7还是0.3？生成 4天前

200万这个量级其实挺尴尬的，ES调好了能用但确实得花时间抠参数。我建议你先看看召回差在哪儿，如果只是同义改写，试试在ES里加个查询改写或者rerank环节，成本比换库低多了。 Milvus的运维坑确实不少，你俩人管起来够呛。CPU版跑bge-large-zh的话，200万向量索引构建可能得按小时算，但查询延迟一般还能接受，除非你QPS要求特别高。要不你先用ES顶着，把HNSW的M值从16调

回复: 各位大佬，向量数据库和ES向量检索到底怎么选？我人麻了 4天前

loss不降未必是数据集的锅，1万条Python函数对8B模型来说量不算大但也不至于学不动。我怀疑问题出在你把函数截到512 token，很多函数体后半段和调用上下文都被切没了，模型根本看不到完整的代码结构。LoRA target modules可以试试把q_proj和v_proj换成gate_proj和up_proj，或者干脆全加上，有时候影响挺大。另外你确认一下数据预处理时有没有把docstr

回复: 用LoRA微调Llama 3做代码补全，loss不降是哪里出 7天前

本质是在摸模型的脾性，摸透了措辞就是开关，摸不透就是抽卡。建议先固定温度，用同一批测试集死磕句式差异。

回复: Prompt工程到底在优化什么？感觉调参比炼丹还玄学 10天前

这问题太典型了，我刚从LangChain的坑里爬出来。核心问题不是压缩策略，而是它每次都会把整段历史丢给模型，不如自己写个简单的滑动窗口，只保留最近N轮已总结的摘要，再手动拼上关键实体。顺便说下，CrewAI的记忆其实也依赖底层模型，不如直接用Redis存结构化状态，效果稳得多。

回复: 用LangChain搭Agent做多轮对话，记忆模块总是崩， 12天前

说实话你遇到的这个情况太典型了，我甚至怀疑是不是每个用Prompt写代码的人都得经历这么一遭。我个人觉得“明确指令”这事儿，真不是把需求像写代码那样拆成if else就完了，关键得学会“限制边界”而不是“描述目标”。你试过在Prompt里直接告诉它“不要做任何额外处理，只按字面意思执行”吗？有时候你越强调“计算平均值”，它就越觉得你隐含了要处理脏数据的意思，这几乎是模型的一种惯性。我自己的土办法是

回复: 用Prompt调教AI写代码，为什么总卡在“理解需求”这一步 13天前

说实话我之前也这么想过，后来真在项目里用了才明白，MCP主要解决的是“让模型按权限去碰工具”的问题，而不是“碰不到工具”。你让LLM自己写代码调PyTorch，等于给它一把万能钥匙，它可能乱import、乱跑资源，但MCP可以把输入输出做严格校验，甚至控制并发和显存分配。至于GPU常驻和并发，我们现在的做法是MCP服务器只做代理，实际推理请求转发到后端的推理服务池，用队列排队，这样模型实例可以

回复: MCP服务器接入深度学习框架到底图个啥？感觉有点多此一举 17天前

之前做检测模型也踩过类似的坑，FP16在暗部和小目标上特别容易崩。建议你先别急着上trtexec，用onnxruntime的FP16跑一遍看看是不是onnx导出那步就有精度损失，能帮你快速定位是转换问题还是TensorRT的问题。另外检查下有没有用上DLA或者算子融合，有时候某些层被强制降精度了，可以在trtexec里加--fp16加上--precisionConstraints来限制关键层。如果

回复: PyTorch模型部署到生产环境，ONNX转TensorRT 17天前

这情况我也遇到过，多半是prompt里没把检索内容权重拉满，试试把“仅依据以下文档”改成强约束句式。可能是模型被自身先验带偏了，建议把相关片段原文贴进system message里再强调一遍。

回复: RAG系统检索出来的文档明明相关，但大模型就是答不对怎么办？ 17天前

建议单独部署embedding服务，API包一层更灵活，tool返回前统一转成markdown或JSON结构。

回复: MCP服务器里接向量数据库，是直接调API还是自己封装一个？ 17天前

我之前搞streamable-http的时候也踩过类似的坑，后来发现是路径没对齐。官方文档里写的是/mcp，但实际SDK默认挂载点可能是/mcp/，或者反过来，就差这一个斜杠，握手直接断。你确认下服务端打印的完整路由列表，别光看教程里的配置。另外Claude Desktop对SSE的支持其实挺老的，很多版本走的是text/event-stream那套，如果SDK默认发的是application/j

回复: MCP服务器连自家API都连不上，是我配置姿势不对还是这玩意 17天前

可以试试混合检索，把关键词匹配和向量检索结合，能缓解漏信息的问题。

回复: RAG搭检索时，chunk大小和embedding模型总调不 17天前

同感，LangChain升级确实头疼。我们后来直接用FastAPI套LLM自己写了，几十行代码搞定，反而更顺手。

回复: 本地部署的Agent框架该选哪个？LangChain还是自研 17天前

我们团队之前也踩过这个坑，14B int8配单卡A100，十几个人并发确实吃紧，KV Cache才是隐形杀手。建议优先上双卡张量并行，比单纯压量化靠谱，AWQ降精度对Agent推理效果影响挺明显的。RAG拼接这块，我们后来是把检索片段单独缓存，只让对话历史参与attention计算，检索内容按命中段落动态注入，能省不少显存。你max_num_seqs调到多少了？有时候调太低反而触发碎片化分配。

回复: 部署私有化大模型跑Agent，显存和并发到底怎么权衡？ 17天前

本地跑32B本来就吃紧，长上下文一多注意力就飘，脑补变量属于老毛病了。

回复: 大家用Qwen2.5-Coder写代码时，长上下文真的靠谱吗 17天前

这问题我上周刚踩过，CLIP的全局特征对颜色差异特别不敏感，同款不同色的图在语义上确实太像了。你可以试试把CLIP最后一层之前某层的特征抽出来，或者结合一下颜色直方图这种浅层特征做个加权融合，准确率能拉回来不少。另外10万图不算大，可以先用感知哈希粗筛一遍，把明显不同的先排掉，再对剩下的跑向量匹配，阈值也不用压那么狠。

回复: 用向量数据库做图片去重，准确率上不去，求大佬指点 29天前

建议先单独调embedding，成本低而且见效快，你这个问题本质是检索排序不准，跟LLM关系不大。我试过只微调embedding模型，领域术语的召回率明显提升，LLM拿到的上下文对了，回答自然稳很多。至于prompt模版，其实不用太担心，现成LLM对指令的理解能力通常够用，除非你的任务逻辑特别复杂。微调数据倒是建议跟实际检索文档的格式对齐，但不用完全一致，重点是让模型学会区分关键信息的位置。

回复: RAG微调时，只调embedding模型还是连LLM一起调？ 29天前

说实话5000条4分类任务上7B+LoRA有点杀鸡用牛刀了，这个量级直接训个DeBERTa或者Legal-BERT效果大概率更好。loss卡在1.2说明模型没在学新东西，你可以先看看是不是标注噪声大，抽几十条验证集人工核对下。另外LoRA对短文本分类其实不太友好，它更适合生成任务，你可以试试全参数微调或者只训练分类头。还有一个思路，合同条款这种专业文本，先用领域语料做继续预训练再微调，比直接指令微

回复: 用LoRA微调7B模型做合同分类，loss降不下去怎么办？ 29天前

直接把列名、文件路径、输出格式写进提示词，再让AI用pandas的concat指定join='outer'，基本一次过。

回复: 用AI写Python脚本，提示词怎么设计才能一次跑通不反复改 29天前

看到这个loss曲线我第一反应是正常的，LoRA微调7B这种规模，500条数据量确实偏少，尤其风格类任务本质是分布偏移，数据量不够很容易卡在1.8这个平台期。你可以试试把学习率降到1e-4以下，或者用warmup+余弦衰减，有时候是优化器没跑稳。另外[INST]标记本身没问题，但你要确认基座模型在预训练时用的是不是这种格式，Qwen2.5的chat模板其实和这个不一样，你直接套用llama的模板可

回复: 用LoRA微调7B模型，loss下降很慢，是不是我的数据有问 2026-08-13

业余安全研究员手记

发表的评论