长期主义商业学习者
Lv.1不过度追求速成，更相信稳定进步。当前重点关注商业分析，通过原型和交互思考、数字化方案落地持续提升能力；习惯用项目结果检验技术判断，并把过程整理成可复用的学习记录。
发表的评论
我实际用下来bge-large-zh在纯中文语料上确实不差，但检索效果跟你的chunk策略关系很大，500字符对技术文档来说偏碎，试试按段落或标题层级切，overlap给到100左右。另外bge对query和passage的指令前缀敏感，检索时query前面要加“为这个句子生成表示以用于检索相关文章”，不加的话效果差一截，这个坑我踩过。openai的3-small在多语言混合场景确实稳，但纯中文知
我也遇到过，后来发现是Cursor默认会把整个文件上下文都带进去，它觉得“顺手帮你优化一下”。我的做法是在prompt里明确写“只新增组件代码，不要动已有的Hook”，或者干脆把Hook文件先关掉再让它写。另外可以试试用@符号只引用需要的类型定义，别让它看到整个文件。
答一半就断这点可以先排除量化，AWQ 掉精度一般不至于断在半句上，更像是 max_tokens 或者 stop token 没配对。对话模板确实值得查，Qwen2.5 的 chat template 里 special token 挺讲究，vLLM 启动时可以手动指定 tokenizer 的 chat_template 试试。我这边 7B AWQ 跑下来格式乱掉的情况，最后发现是 generati
1.5k的prompt太长了，prefill占大头，QPS上不去很正常，先看看是不是卡在prefill阶段了。
这坑我踩过，大概率不是 schema 的问题，是模型压根没把“先检索”当成硬约束。你试试把检索做成 tool 而不是前置步骤，让模型自己决定调 retrieval 再调业务工具，链路反而稳定很多。另外工具参数里别让它“记得”带检索结果，直接在 server 端做上下文注入或者用引用 id 传递，比靠 prompt 提醒靠谱。
学到了，感谢分享！
刚入门，这个对我帮助很大。
我遇到过类似情况，大概率是每次把完整历史拼进去导致KV cache没复用，白白重复算。你可以看看是不是每次调用都重新encode了整段对话，那样显存肯定涨。建议把历史对话截断到固定长度，或者用vLLM这类支持cache复用的推理框架，比裸PyTorch省很多。外部API返回结果喂回去之前记得detach掉中间张量，别把没用的计算图挂着。
8G显存跑本地模型确实得掂量下，Qwen2.5-Coder的7B量化版勉强能塞进去，但上下文一开大就爆显存，补全延迟明显，写业务代码时那种等半秒才出提示的体验挺劝退的。我现在的组合是Tabby做行内补全、Continue挂DeepSeek-Coder做对话式修改，跨文件重构这块基本还是得靠自己拆步骤，别指望它一次改对，把任务切小、每次只让它动一个文件，准确率能上来不少。理解项目结构这事开源方案普遍
有没有更详细的教程推荐？
这个思路不错，收藏了。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
有没有更详细的教程推荐？
这个思路不错，收藏了。
学到了，感谢分享！
学到了，感谢分享！
GPT-2默认输入是int token id，你得把embedding层输出和prompt向量拼一起再送进模型，别直接传id。
子任务拆开单独跑一遍，稳定了再串回流程里，跑偏一般是上下文串味了。
这坑我熟，本质是模型分不清什么时候该检索、什么时候该调工具，光靠prompt很难卡准。我的做法是把检索也包装成一个tool，让模型自己决定先调哪个，同时在工具参数里留个字段接收检索结果，schema上强绑定。另外MCP那边最好加个中间层做编排，别指望模型一次想清楚两步。你可以在system prompt里明确写清依赖顺序，但更稳的还是用状态机控制流程。