阿哲Growth手记
Lv.1Techlearner，保持学习，也坚持亲手验证，技术方向以Git与工程协作为主。持续整理性能优化、项目复盘和可复用的工程方法；关注技术选择背后的成本与边界。
发表的评论
试试先粗排再精排，用cross-encoder重排top50，比单纯调top_k靠谱，分段时按章节切别硬截。 之前踩过坑，直接调阈值没用，得结合query和chunk的相似度分布动态过滤，噪音能少一半。
试试把检索结果里没有的内容明确标成“未知”，再在prompt里加一句“没找到就直说不知道”，比单纯强调“只基于”管用。 prompt写“只基于”确实容易被当成耳旁风，我后来是让模型先复述检索到的点，再单独列“推测”，它才老实点。
5-7 tok/s确实不太对劲，我拿4080跑过7B Q4，llama.cpp单线程都能到15+，你这情况八成是线程数没给够或者mmap没开。延迟想压到2-3秒得看总输出长度，如果只生成几十个token那换vLLM会有明显提升，但短请求的调度开销也得考虑。16G跑7B完全够，问题肯定不在显存大小，你可以先试试把threads调到16或者用最新的llama.cpp带flash attention的构
我倒觉得这事儿不全是Cursor的锅，它本质上是按“最佳实践”来生成代码的，而咱们日常业务里大部分场景根本用不上那套东西。你给它一个具体需求，它默认就会往工程化、可扩展的方向走，好像不塞几个hook就显得不专业似的。我后来学乖了，会在prompt里直接加一句“不要抽象，不要优化，只要最直白的实现”，效果立刻不一样。另外，它生成的那些memo和useCallback，很多时候其实是在帮你预防未来可能
试试在生成前把关键变量名写进一个固定命名规则文件里，让它每次生成前先读一遍，我这么干之后报错少多了。
查日志别只看进程起来了没，重点是握手那一段的输出，MCP的stdio模式对启动参数和协议版本要求很严格，0.6.0跟新版Claude Desktop确实可能对不上，我上次就是降级SDK到0.5.x才好。另外SSE模式要确认服务端有没有正确返回`endpoint`字段，格式不对客户端根本不认。你试试直接用curl模拟客户端发个initialize请求，看响应是不是标准的MCP JSON-RPC格式，
第三条太真实了，拆成独立工具调用反而更可控，长链路归因就是玄学。
说实话你这结果挺常见的，LoRA在小规模数据上确实容易跑偏，尤其中文任务对基座模型的词表覆盖很敏感。我建议先看看你用的中文alpaca子集质量，很多开源数据集本身就有不少噪声，2万条里混着英文或翻译腔很影响效果。另外分词倒不是必须的，但可以试试把中文数据重新清洗一遍，去掉那些带英文的样本，或者干脆换个中文预训练模型比如Baichuan或者Qwen，直接省掉很多麻烦。还有个小细节，epoch可以降到
几十万条量级真不用纠结，FAISS本地跑完全够用，等数据涨了再换Milvus也不迟。Pinecone免费额度做demo是够的，但长期用确实得算笔账。
别直接用Q-A对硬怼，那个是给生成模型用的，检索模型得构造（query，正doc，负doc）三元组。我踩过的坑是负样本别全用随机采样，得挖一些hard negative，比如top-20里但标签不对的，效果提升很明显。比例的话，1:3到1:5我都试过，感觉1:4左右最稳，但得看你数据难度。另外建议先拿你实际场景里的query做一批人工标注，比纯自动生成靠谱多了。
我之前也踩过这个坑，1:1:1真不行，代码和数学这种高方差任务会疯狂挤压客服和通用能力。建议把通用数据提到50%以上，代码和数学各20%左右，epoch别统一，通用数据训2轮，任务数据训1轮就够。LoRA确实能缓解，但rank别调太高，我试过32效果反而不如16，另外你试试把客服任务单独抽出来最后用低学习率续训几个step，通用能力能保住不少。
大概率是切分太粗+没rerank，bge-m3对长文本语义捕捉有限，建议先试下滑动窗口切分或加个轻量rerank，混合检索可以先放放。
数据格式问题更大，工具描述和示例得对齐真实调用，不然模型学不到“什么时候该调”的边界。 我之前也踩过这坑，建议把每个API的触发条件写死，多塞点正例，负样本别乱混。
传输层真不用死磕stdio，我们生产环境直接gRPC接MCP，性能稳得很，JSON-RPC那套够用就行。负载均衡建议丢给Ray，别在MCP层瞎折腾，省心。
我们组正好用Qwen2.5-7B做过类似场景，vLLM下A100单卡跑16并发左右TTFT就开始飙到1.5秒以上了，你网上看到的20实例估计是纯看显存没算KV cache和prefill的波动。建议先别急着上4卡张量并行，那个对7B模型收益不大，通信开销反而拖慢单请求延迟；2卡各跑一个实例做负载均衡更实用，还能顺便扛单点故障。量化到AWQ 4bit我们试过，知识库问答这种短query场景掉点其实不
试试在prompt里加一句“如果原文没有就直接说不知道”，顺便把检索片段拆成带编号的小段喂进去，效果会稳很多。
维度真不是越高越好，1536维在FAISS里走暴力检索或者IVF参数没调好，索引大了速度掉得厉害很正常。我个人经验是，先看你数据集的语义粒度，如果段落主题差异比较明显，512维其实够用，关键是用合适的模型去对齐维度，比如bge-large或者e5-large都有512维版本。混用不同维度模型最麻烦的是没法直接比较相似度，建议你统一模型，别混着来。另外检索慢的话，可以试试加粗量化或者HNSW，比单纯
4bit量化对7B这种小模型的影响确实挺明显的，尤其是生成摘要这种需要精确抓重点的任务，信息密度一高就容易丢细节。你可以试试用GPTQ或者AWQ重新量化一下，或者干脆用FP16跑，显存不够就换更小尺寸的模型，效果可能比牺牲精度硬上更划算。另外本地部署的prompt确实得写得“啰嗦”点，比如明确告诉它“先提取所有技术名词再组织语言”，或者给一个示例输出格式，比单纯调温度参数稳定多了。我自己的经验是，
其实混用BGE+rerank是值得的，检索质量差太多，显存不够可以量化或者换小模型跑。
把知识库检索到的内容塞进system message里，同时限定只答库内信息，比单纯靠prompt硬压靠谱得多。