长期关注项目管理实践笔记

先查一下ONNX和PyTorch的输出差多少，八成是某层算子对不上，别急着换TFLite。

这个“过度设计”的问题我也遇到过，感觉Cursor默认确实有一套自己的审美，像是从那些star过万的开源模板里学来的。我后来发现光在rules里写“保持简单”基本没用，它该拆还是拆，得配合项目根目录的.cursorrules文件，把具体反例写进去，比如“禁止创建单文件超过80行的组件”“禁止为一次性逻辑抽Hook”，越具体越管用。另外你可以在对话里直接引用现有代码，说“按这个文件的风格来”，它模仿

用sglang的话可以试试outlines或者xgrammar做约束解码，比在prompt里写JSON schema靠谱多了，字段名直接从语法层面锁死。Qwen2.5本身对tool call格式的遵循还行，你可以把抽取任务包装成function calling，schema里把字段和类型都定死，比纯文本prompt稳不少。few-shot不用全字段都写，挑三五个典型难例放进去就够，token压力没

几万条切片真没必要上Milvus，我自己的知识库差不多量级，Chroma跑得挺稳，慢主要是元数据过滤没建索引。你要是担心以后涨，不如先看看Qdrant，单容器部署比Milvus轻多了，过滤性能也不差。迁移成本其实不高，数据和embedding都在，换个client重新灌一遍就行，别被一步到位绑架了。

16G显存跑7B加RAG确实挺紧的，我之前也卡过这。后来把上下文砍到8k以内，检索只塞top2片段，记忆用摘要滚动更新，反而稳了不少。vLLM吃显存主要是KV cache，可以调gpu_memory_utilization和max_model_len压一压。CPU那边我试过llama.cpp加Q4_K_M，速度能忍但别指望流畅，纯CPU还是适合异步跑。

loss降了但输出乱码这个组合其实挺常见的，loss降不代表模型学会了格式，它可能只是在过拟合你的QA模板。8000条数据对医疗领域来说不算多，关键是看你的prompt结构，如果训练时没有固定一套类似“### 问题: ... ### 回答: ...”的模板，推理时模型就不知道该怎么续写，容易崩成重复token或者中英混杂。学习率2e-4对LoRA来说偏高了一点，rank=8也偏小，医疗这种专业领域

我也被这个问题折磨过一阵子，确实挺让人头大的。后来发现关键在于别让模型自己“脑补”上下步的连接，而是把每一步的输入输出格式卡死，比如第一步必须返回一个带列名的JSON，第二步只允许从这个JSON里取值，这样它就没法胡编了。另外MCP本身不负责帮你拆子Prompt，它更像一个工具调用的通道，所以嵌套逻辑得你在外层自己用状态机或者变量传递来管。我试过把整个流程写成一个带明确依赖标注的YAML，每一步都

Qwen和Llama对温度敏感度确实差挺多，我这边Qwen2.5用0.6左右比较稳，Llama3.1基本得压到0.3以下才不飘，感觉跟训练数据和对齐策略有关。结构化输出别硬调prompt了，直接上JSON mode或者用outlines、lm-format-enforcer这类库约束解码，省心很多。few-shot被忽略的话可以试试把格式要求放到system里，或者最后再加一句强调，位置挺关键的。

2000条数据做客服问答确实有点紧，模型容易过拟合到固定模板上，loss卡在2.3不算离谱。你试试把rank提到16或32，学习率降到1e-4，再检查下数据里问题答案是不是格式太单一了。重复提问内容很可能是训练时prompt模板没对齐推理时的输入格式，这个坑挺常见的。24G跑7B全量基本别想，LoRA继续调参更现实，先把验证集loss和生成质量分开看。

2万份PDF的体量下，纯生成模型做检索确实容易翻车，它本身不是拿来算相似度的。BGE+reranker这条路效果稳，但3090单卡同时扛两套确实吃紧。可以试试把reranker换成量化版或者只对top20重排，显存能省不少。另外Qwen2.5也有embedding版本，你要不试试统一用它,省得维护两套。

我也踩过这个坑，后来发现纯按字数切本身就有点问题，因为语义边界根本不在固定字数上。现在我会先用语义切分或者按标题层级切，再对超长的块做二次拆分，效果比一刀切200或1000好不少。检索差不一定全是chunk size的锅，还得看你的query和文档表述差多远，有时候加个rerank模型比调切分参数管用得多。评估这块我一般会准备一组问题加标准答案，手动看召回的前几个chunk里有没有能支撑答案的内容

我最近也踩过类似的坑，MCP这层stdio的坑其实挺多的。你说模型端已经吐出了JSON参数但server没收到，这个描述很关键——大概率不是timeout太保守的问题，而是stdio的缓冲和换行处理上出了岔子。Python里如果用的是subprocess或者sys.stdin.read()阻塞读，很容易因为没读到明确的换行或EOF就卡死，Claude Desktop那边等不到完整响应自然就超时了。

存原始文本是必须的，不然检索回来一堆embedding你没法喂给LLM，还得再查一次库，纯属给自己找麻烦。但你说的每次把整段历史重新向量化，这个操作本身就有问题，正确做法应该是按轮次或者按语义块切分后单独存，每块带自己的embedding和原文，再加个session_id、timestamp、turn_index这些metadata。重复旧内容大概率是因为你整段历史向量化之后，相似度天然就高，检索

几十人用sqlite-vec完全够，但备份得做WAL归档，不然索引一崩就哭吧。

Qwen2.5的function calling其实还算稳，但本地跑量化版的话确实容易抽风，参数类型乱传多半是模型对schema的理解没对齐。建议把工具定义里的参数描述写死一点，比如明确写“city必须是字符串，如北京”，再在system prompt里加一句“调用前先检查参数类型”。另外可以试试Hermes-2-Pro或者Mistral-Nemo，这俩对tool use做过专门微调，比裸Llam

量化到4bit后12G其实挺正常的，7B模型权重本身就占4G左右，加上推理框架的overhead、激活值和KV cache，4090的24G跑长上下文确实紧张。你LoRA合并再量化一般不会丢效果，但如果校准数据跟你的JSON任务差太远，量化后格式遵循能力可能掉一点，可以拿几十条测试用例对比下。想稳跑百轮对话，建议试试vLLM加GPTQ/AWQ，开PagedAttention能省不少KV cache

你这问题我踩过，大概率不是清洗逻辑的问题，是让Agent生成SQL本身就不太靠谱。我后来改成让第一个Agent只输出结构化JSON，用langchain的PydanticOutputParser卡住格式，SQL字符串单独放一个字段，换行和引号都好处理。第二个Agent压根别让它碰SQL，直接拿解析好的字段去执行，省得它自作主张。

试过按段落+带128重叠，技术文档效果还行，聊天记录得切小点，不然语义太散。

对话历史塞进system prompt是最容易犯的错，试试用ConversationSummaryMemory做摘要，再加个向量检索只召回相关的几轮。

这问题太典型了，LoRA微调只动生成头，不动检索链路，embedding自然被带偏。我之前试过把微调数据里抽20%出来，专门做对比学习，强制模型在生成时保留检索相关性，效果能稳住不少。另外你查查是不是温度参数被调高了，生成随机性变大也会干扰召回。