刺猬不想加班日记

这个思路不错，收藏了。

BM25能命中说明关键词匹配是有效的，问题大概率出在chunk切分把操作步骤拦腰截断了，512字符固定切对步骤类文档很不友好。建议先试试按标题或段落结构切，再对步骤类内容做小chunk加父文档回溯，这个改造成本比换模型低。text-embedding-ada-002对中文长尾术语确实一般，但bge提升不明显反而说明瓶颈不在模型。另外可以加一路BM25做混合检索，RRF融合一下，操作类query的召

COT适合拆解逻辑，但排序优化直接给伪代码约束更靠谱，让它自己推理容易跑偏。

写得挺好，建议补充一些性能数据。

刚入门，这个对我帮助很大。

有没有更详细的教程推荐？

这个思路不错，收藏了。

我也遇到过类似情况，检索到的chunk确实有预算数据，但Qwen就是不爱往外吐。后来发现加个rerank（比如bge-reranker）把最相关的chunk排前面，再在prompt里明确要求“必须逐项列出技术方案和预算的对应关系”，效果就好了不少。建议你先别急着换模型，把prompt约束和rerank加上试试，比调top_k管用。另外跨章节问题可以试试多路检索再合并，单次检索容易漏。

我之前也踩过类似的坑，光在prompt里加“严格遵守”基本没用，模型该跑偏还是跑偏。后来改成用response_format强制JSON输出，把注释字段单独拎出来，稳定性提升特别明显。温度调到0.2左右确实有帮助，但更关键的是few-shot示例要覆盖边界情况，比如函数本身已经有docstring、或者带装饰器的场景。另外你可以在prompt里明确说“如果函数已有注释就原样返回”，不然它容易自作主

同感，4090跑Agent确实挺尴尬的，模型本身吃一半显存，剩下那点还要扛多轮对话和工具返回，稍微一长就崩。我之前用Qwen2.5-14B也是这情况，后来换成7B的AWQ量化版本，加载完大概6G出头，明显宽裕不少，但代价是工具调用的准确率会掉一点，得看你的任务复杂度能不能接受。另外工具返回结果真的一定要截断，特别是那种API返回一大坨JSON的，我一般只保留关键字段再塞回去，不然上下文膨胀得飞快。

5000条数据跑10个epoch确实容易过拟合，loss卡住不动可能不是学习率的问题，而是LoRA的rank=8对7B模型来说容量太小了，试试调到32或64。另外你确认下数据格式有没有问题，Qwen2.5的chat template如果没对齐，loss确实降不下去。领域微调一般不用继续预训练，直接SFT就够了，5000条够用，关键看数据质量和prompt构造。

7B模型fp16权重本身就占14G左右，KV cache才是大头。你max_model_len 4096配batch 8，光KV缓存就要吃掉不少，gpu_memory_utilization 0.9基本等于把卡榨干，并发一上来肯定OOM。想省显存可以试试量化到int8或者fp8，或者把max_model_len往下压，batch别死磕8，vLLM的continuous batching本来就能动态

我也踩过这坑，后来把判断逻辑放到检索后，先让模型看到内容再决定答不答，幻觉少很多。

我之前也踩过这个坑，后来发现核心问题不在约束多少，而在于你把“审什么”和“怎么审”混在一个Prompt里了。GPT-4做代码审查时，如果让它同时兼顾命名、长度、bug、性能，注意力会被稀释，漏掉拼写错误太正常了。我现在是拆成两轮：第一轮只让它输出所有可能的异常点，不给任何评判标准，相当于“系统1”快速扫描；第二轮再针对每个异常点用单独Prompt深入分析，这时候它反而更稳。另外正反例确实有用，但别

我之前也踩过这个坑，感觉不一定是模型注意力的问题，LangChain里工具调用的中间结果经常没被正确塞回上下文，尤其多步链式调用时容易丢状态。你可以先打印每步的完整prompt看看，八成是框架把历史截断了。换Yarn-Mistral治标不治本，先把Agent的memory机制理顺更划算。

K8s 里 MCP 超时坑挺多的，我之前也踩过。先查下 Service 的 sessionAffinity 是不是没开，默认轮询会把同一个客户端的请求打到不同 Pod，连接自然就断了。另外看下 Ingress 或 LB 的 idle timeout，很多默认 60 秒，比 MCP 的 heartbeat 间隔还短，心跳还没发出去连接就被掐了。ServerCapabilities 一般不至于导致超时

2048的序列长度下batch size 4还OOM，单卡80G确实有点不对劲，大概率是别的地方在吃显存。你可以先检查一下有没有把optimizer的显存开销算进去，QLoRA虽然权重压到4bit，但LoRA的adapter参数、梯度以及优化器状态在Adam下还是挺可观的。另外transformers默认可能会把整个模型load到GPU上再做量化，中间峰值会飙得很高，试试用device_map或者

几千份PDF其实不算小，Chroma本地玩玩可以，真上量了内存和检索延迟确实顶不住。我建议先别急着上Milvus，可以试试Qdrant，部署比Milvus轻不少，单机Docker就能跑，性能也够你团队用。Chroma优化分块和索引能撑一阵，但迁移成本早晚要付，不如现在选个中间档的。Weaviate功能全但学习曲线陡，除非你要用它的混合检索，不然Qdrant性价比更高。

我用了大半年Copilot也有类似感觉，但后来发现退化最明显的是“从零写”的能力，读代码和改bug反而变强了。我的做法是每周抽半天关掉AI补全，纯手写小模块或者刷刷题，就当保持肌肉记忆。混着AI代码维护确实头疼，尤其是风格不统一和边界条件被忽略，建议AI生成的部分加注释标出来，方便以后排查。

把工具描述写短反而更稳，我现在的做法是每个工具只留一句“什么场景用”，参数说明塞进JSON schema的description里。Prompt里专门加一句“不确定就先用tool_search问一句再动手”，Claude调用前会自己确认下。另外工具名用动词开头比名词堆叠好认很多，选错率能降不少。