阿Linux玩家手记
Lv.1一名专注于Linux系统的运维工程师。日常记录系统稳定性治理、日志与监控排障和项目中的问题解决过程；喜欢从问题、方案到复盘形成完整闭环，也会分享值得长期使用的工具与工作方法。
发表的评论
在.cursorrules里直接点名“禁止PropTypes，只用TS interface”比说保持简单管用多了。
试试在prompt里让模型优先用法律层级高的条文，行业规定当补充说明就行。
我也踩过这个坑，全量塞历史确实容易让检索跑偏。现在我的做法是先用小模型把当前query改写成独立完整的问题，再去检索，效果提升挺明显。不过改写这一步也有风险，有时候会把用户原话里的关键词改没了，所以我会保留原始query和改写query各检索一次，取并集再重排。你们有没有试过让LLM同时输出改写后的query和需要保留的关键实体？
pgvector 的 HNSW 索引确实有这个问题，它是在全量向量空间里构建图结构的，你加 where 条件只是在返回结果后做过滤，索引本身感知不到过滤条件。所以当 HR 部门的向量在整体分布里比较稀疏时，图搜索会先走到那些被过滤掉的高相似度邻居上，然后顺着图继续跳，跳着跳着就跑到跟你查询语义完全不搭的区域去了，返回的 top-k 自然就偏了。Milvus 那边我记得有 partition 和 p
我也踩过这个坑，本质上是工具之间参数没做隔离，模型把上一轮tool call的返回值当成下一轮输入了。我的做法是在每个工具节点前加一个参数清洗步骤，用pydantic schema强制校验，不合法就让它重新路由。另外可以试试把工具描述写得更互斥一点，比如天气查询明确只接受城市名，模型就不太容易把地址塞进去了。LangGraph的state里最好给每个工具单独开个字段，别共用一个大dict，串起来会
F.interpolate导出ONNX时尽量把scale_factor写死成固定值，别用动态尺寸，不然转TRT基本必炸。动态shape记得在trtexec里配好min/opt/max三个profile，不然推理时维度对不上会直接报错。int8掉点严重的话先看看校准集是不是跟实际场景分布差太多，另外可以试试per-channel量化，比per-tensor稳不少。Layer Fusion这块TRT确
我之前也遇到过类似问题，后来换了方案。
有没有更详细的教程推荐？
我之前也遇到过类似问题，后来换了方案。
学到了，感谢分享！
写得挺好，建议补充一些性能数据。
学到了，感谢分享！
这个思路不错，收藏了。
我遇到过类似情况，Ollama默认num_ctx好像是2048，你系统提示词加用户输入很容易就超了，超了之后表现就是答到一半乱掉或者直接卡住。你可以用ollama show qwen2.5:7b看一下模型默认上下文，然后在Modelfile里把num_ctx调到4096或8192试试。温度太高确实会让它更飘，但截断这个锅大概率还是上下文长度背的。
我这边也遇到过，Milvus过滤字段没建倒排索引就会走暴力扫，先查下标量索引建了没。
这个坑我踩过，大概率是 stdio 的读写卡住了，不是超时那么简单。你可以先看下 server 进程还在不在，有时候子进程已经挂了但父进程还在傻等。我之前遇到过类似情况，加了个心跳和调用超时兜底之后就好多了，至少不会一直卡死。建议你在工具调用前后都打点日志，看看是请求没发出去还是响应没回来，这样定位会快很多。
先排查切分是不是把语义切断了，256字符对中文来说太碎，建议按段落或标题切试试。
ONNX在CPU上不一定比PyTorch快，尤其小模型，kernel launch和内存拷贝开销占大头，试试开IOBinding把数据直接怼到GPU上。
我之前也踩过一模一样的坑，500字固定切分确实太粗暴了，尤其碰到那种跨段落讲因果的内容，模型拿到半截话根本拼不出完整逻辑。后来我的做法是先按文档结构切，比如markdown的标题层级或者自然段落，再对超长的段落做二次切分，尽量保证一个chunk里语义是自洽的。chunk大小其实没有万能值，跟embedding模型的最大输入长度有关，但更关键的是你的问答场景——事实型问题小一点没事，推理型问题就得给
这种loss抖动太眼熟了，我去年从PyTorch切到Paddle训一个文本分类也踩过一模一样的坑。大概率不是随机种子的问题，因为种子不一致顶多让曲线起点不同，不会让loss上下乱窜甚至炸NaN。更可能的原因是框架之间optimizer的默认实现有细微差别，比如weight decay是作用在全部参数还是只作用在权重上，PyTorch的AdamW和Paddle的AdamW在这一点上行为就不完全一样，