持续迭代商业成长记

500条这个量级其实挺尴尬的，说少不少说多不多，关键还是看你想让模型学什么。我之前做垂直领域的风格迁移，300条质量高的数据效果就挺明显了，但换成知识注入类的任务，2000条都还差点意思。所以单纯问“需要多少条”意义不大，得看任务的复杂度和数据的信息密度。你这500条如果覆盖的意图比较分散，确实容易欠拟合，可以试着先看训练loss和验证集表现，如果loss降不下去或者过拟合很快，那问题可能不在数量

我之前也卡在这个阶段很久，后来发现一个关键点：JSON格式出错往往不是prompt本身的问题，而是模型在长输出时容易“走神”，尤其是分类和摘要混在一起做的时候。我现在会把任务拆成两次调用，先分类再摘要，稳定性明显好很多。另外温度调到0确实不等于确定性输出，GPT-4背后还有系统层面的非确定性，这个坑我踩过。关于评估工具，我目前用的是一个简单的A/B脚本，跑同一批测试集对比两个prompt版本的字段

AWQ掉点主要在代码和推理上挺常见的，4bit对attention和FFN权重的扰动在长上下文时会被放大，你2k就OOM其实更可能是KV cache没管好，不是权重的问题。4090跑7B FP16权重才14G，剩下10G给KV cache，2k上下文按理说不该炸，建议先看看是不是框架默认预分配了最大长度。vLLM的PagedAttention确实能省不少，配上gpu_memory_utilizat

你描述的这个现象我遇到过类似的，基本可以确定是LoRA权重动态合并带来的开销。vLLM在推理时如果没提前把LoRA merge进基座权重，每次forward都要做额外的adapter计算和合并操作，7B模型上这个损耗确实能到接近一半，尤其你max_model_len还开到4096，长序列下更明显。建议试试用peft的merge_and_unload把LoRA权重合并进基座再导出完整模型，然后用me

我之前也遇到过类似问题，后来换了方案。

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

我之前也遇到过类似问题，后来换了方案。

4060 8G跑7B确实有点勉强，不光是模型权重的问题，上下文一长KV cache也跟着涨，swap基本是必然的。可以试试1.5B或者3B的coder版本，补全场景其实够用了，我拿3B跑日常补全延迟很低，基本感觉不到卡。另外Ollama可以调一下num_ctx，默认上下文给太大了，改成2048或者4096能省不少显存。如果非要7B，试试Q4_K_M以下的量化，再配合--n-gpu-layers只卸

几十万切片真不用上Milvus，pgvector就够用了，省心省事。我之前RAG项目用的Qdrant单机，部署轻量并发也还行，比Chroma稳一点。结构化信息建议放Postgres里，向量库只存id和embedding，检索完回表拿原文和元数据，别全塞向量库。Milvus Lite迁正式环境不算麻烦，但小团队前期折腾部署真没必要，先跑通业务再说。

你这个情况我第一反应是分块的问题偏大一些。500字符固定切分对产品手册这种结构化文档挺致命的，标题和正文被切断之后，一个chunk里可能前半段讲保修后半段讲安装，embedding再强也救不回来。我建议先别急着换模型，拿几个badcase把召回的chunk原文打出来看看，如果发现片段本身语义就混杂，那基本能确认是切分粒度的事。bge-large-zh-v1.5对中文长文本其实还行，但它对输入长度有

PDF技术手册按章节切比较好，RecursiveCharacter一刀切容易把上下文切碎，先换分块策略试试。

我一般控制在2-3个例子，而且尽量让例子的句式差别大一点，不然模型真的会往一个模子里套。之前也踩过坑，给了四个同结构的正例，结果生成的全是一个味道，换都换不掉。后来改成给两个风格差异明显的例子，再加一句明确的指令说“不要照搬示例句式”，效果好很多。你可以试试把例子当参考方向而不是模板，指令里强调多样性。

你这种跳步问题，光靠prompt确实很难稳住，不如直接上LangGraph把节点卡死，每步校验通过才放行。

这个场景太典型了，我上个月刚踩过几乎一模一样的坑。你描述的问题里“把其他合同的段落也捞出来”这点很关键，它其实暗示了embedding在区分细粒度语义时确实吃力，但更根本的原因可能是你的分块把“违约金计算标准”这个完整语义切碎了，导致检索到的片段都是半截子话。bge-large-zh在中文通用场景下不算弱，但合同文本里充斥着大量重复的格式条款和相似句式，模型很难单靠语义向量就把不同合同里的“违约金

我之前也踩过这个坑，全局dict并发下确实会串数据。后来我是用Redis按session_id存状态，MCP server这边只做无状态的推理入口，每次请求带上session_id去捞。MCP的Resource其实挺适合挂这种会话状态的，当成可读写的上下文资源来用，比硬塞进tool参数优雅。不过多轮对话里模型记忆和LLM上下文割裂的问题我也没完全解决，感觉还是得靠一个中间层做状态同步，纯函数方案对

我之前也踩过这个坑，chunk_size 512 对报销流程这种多步骤文档确实容易断片，关键信息被切到下一个块里，召回时只匹配到标题那块。建议先别急着换 embedding，把 chunk 按标题或段落切，overlap 拉到 100 左右试试，成本最低。混合检索确实有用，BM25 能兜住那些向量漏掉的关键词匹配。gte-Qwen2 提升肯定有，但前提是你 chunk 别把语义切碎，不然再强的模型

之前也折腾过类似的美化方案，直接替换asar确实升级就炸，深有同感。不过好奇Dream Skin这种钩子注入会不会和某些插件冲突，毕竟拦截文件读取API这层如果没处理好，性能损耗和兼容性都是坑。另外如果Electron升级了大版本，适配器维护成本可能也不低，得看作者能不能持续跟进了。

工具调用这块我现在基本放弃了指望模型一次就调对，太不现实了。我现在的做法是把每个工具的参数校验做得很死，schema 写严格一点，类型不对、必填缺失直接打回去让模型重试，别让它带着脏参数往下跑。另外重试策略也挺关键的，不能无脑重试，得区分是网络抖动还是模型压根理解错了，前者可以retry，后者重试多少次都没用，不如把错误信息塞回去让它重新想。还有个坑是工具返回结果太长，模型容易看花眼，我现在都会做

物理世界落地确实难，连抓取都搞不定重力，更别说因果推理了。不过数据闭环这块我倒觉得比堆模型更有戏。

这个我深有体会，之前做知识库问答也踩过类似的坑。我们的经验是模板别写太长，角色设定一句话就够了，比如“你是XX公司的客服助手”，剩下的靠system prompt里挂约束条件，比如“不知道就说不知道”，比堆一堆人设管用。太复杂的模板确实容易让模型跑偏，尤其Llama 3这种对指令比较敏感的，信息一多它就开始自己脑补了。至于稳定性，我建议把模板拆成固定前缀加变量，前缀部分尽量精简，变量只放用户问题，