一只刺猬追着需求跑

这问题太真实了，我刚开始用的时候也差点被气疯。后来发现它其实是按照代码库里的“最佳实践”在猜，但咱项目根本没那需求。你可以试试在项目根目录放一个`AGENTS.md`文件，把组件风格、props规范写进去，针对性会强很多。另外如果你经常删同一个props，直接在代码里写个例子让它模仿，比在prompt里喊话管用。AI确实容易过度设计，本质是它在平衡各种可能性，需要靠规则去约束它。

我之前也纠结过这个问题，最后是单独起了个embedding服务，MCP里只做调度。工具里直接调用模型虽然省事，但每次查询都走一遍推理，延迟真能到几百毫秒，尤其文档多的时候特别难受。Qdrant的插件方案我没试过，不过感觉它内置的应该优化过，你可以先小规模测下看看吞吐。还有个坑是切片的粒度直接影响召回效果，别光顾着embedding，chunk大小和重叠得多调调。

说实话，最后那个混合技术栈的问题才是关键，单场景跑通跟真实项目落地完全是两码事。 能自动补mock数据这点确实实用，但就怕换个冷门框架又原形毕露。

几百万条对pgvector来说其实已经到临界点了，尤其如果你用OpenAI embedding默认1536维，那索引体积和扫描成本会翻倍暴涨。建议先查下是不是没走IVFFlat或者HNSW的合适参数，还有work_mem和effective_cache_size调没调过。真要换Milvus的话，延迟确实能降，但运维复杂度也会上来，小团队得有心理准备。不如先试试把向量表按业务id做分区，再加个pg_

这问题太典型了，我当初也踩过坑。轻量级做法可以试试把上一轮的query和当前问题做个简单拼接，但别全拼，只保留实体和关键限定词，比如“今年财报的利润”。再不行就给历史对话加个权重，检索时优先匹配最近一两轮的高频词，效果比直接堆query干净不少。

我自己试下来最管用的是把“约束”和“背景”彻底分开写，比如先甩一段纯背景，然后单独用“硬性要求：”把核心逻辑列成清单，模型基本就能分清了。另外问题顺序挺重要的，关键约束放最后反而容易被忽略，放开头或者紧挨着输入示例效果更好。你可以试试用XML标签或者分隔线把重点包起来，比单纯说“注意”有用多了。

说实话，你这情况我遇到过好几次，多半不是LoRA没加载，而是微调根本没学到东西。几百条客服对话对7B模型来说真的太少了，尤其是LoRA本身参数量就小，数据量不够它根本抓不住你想要的风格偏移，输出自然就退回到基座模型的知识惯性里。你可以试试两个方向：一是把rank提到16甚至32，让可训练参数多一点，二是检查一下是不是只有最后几层在生效，有时候只调了attention层，其他层没动。另外5e-4的学

我24G卡跑7B LoRA，batch size设1加梯度累积4步，loss曲线还算稳。

同感，之前我也被这个问题卡了很久。试过在检索后加一个轻量级的交叉编码器做重排序，效果比纯向量相似度好不少，比如Cohere的rerank或者自己微个小模型。另外可以试试让LLM先对检索到的chunk做个相关性打分，再只拿高分的去生成回答，虽然多一步但准确率提升很明显。

AI默认追求“能跑就行”，边界情况得靠你主动在prompt里给具体例子，比如“文件不存在时返回空列表”。

说实话，豆瓣的反爬没那么玄乎，但新手确实容易踩坑。你遇到的几个问题我一开始也全中，简单聊聊。 先说User-Agent，光换那个没用，豆瓣这类网站现在看的是请求头完整性。比如`Accept-Language`、`Referer`这些字段，AI生成的代码经常只给个User-Agent，其他全默认，一对比就很可疑。你可以让Cursor帮你补全一个接近真实浏览器的请求头，或者直接让它生成用`reque

24G跑7B int4按理说应该够用，问题大概率出在并发和kv cache上。max_num_batched_tokens调小后还有OOM，可以试试把gpu_memory_utilization设到0.85以下，给vLLM留点缓冲，再配合--enforce-eager模式降低显存碎片。FlashAttention肯定要开，能省不少显存，换TensorRT-LLM也能压一些，但门槛高不少。如果业务并