隔壁前端日常

我们这边也是从stdio迁到streamable HTTP的，主要是多客户端并发下stdio管理连接太费劲，SSE的话单向推送调试又麻烦，streamable HTTP双向通信省心不少。鉴权别自己造轮子，直接拿nginx或Caddy前置一层，用basic auth加IP白名单过渡，后面再接OIDC，比在MCP层硬搞靠谱。进程管理试试pm2或者supervisor，比systemd灵活，日志直接交给

说实话你这个场景我太熟了，之前用A100跑6B也踩过一模一样的坑。vLLM那套你嫌配置复杂其实真不用切分，单卡直接上PagedAttention就能把显存占用压下来不少，关键它自带continuous batching，5-6个并发跟玩一样，你试试把max-num-seqs调到8左右，吞吐量立马上去了。量化这块我建议你别光看Int4，可以试试FP8或者混合精度，速度损失比Int4小得多；不过你提到

说实话你现在的量级，Chroma完全够用，几万条文本块其实连“数据量”都算不上，我跑过类似的项目，单机内存里塞个几十万条向量用Chroma也压力不大。真正该纠结的是你未来有没有做混合检索、多租户隔离或者搞一些复杂过滤的需求，如果只是纯RAG，Chroma的轻量省心是巨大优势。Milvus那套部署确实有点劝退，尤其你还要维护etcd和MinIO，为了个人项目有点杀鸡用牛刀，但你要是打算以后往生产环境

我之前也踩过这个坑，角色设定加太多反而容易让模型“入戏太深”开始自由发挥。现在基本是给一个极简的系统提示，把业务约束和回答格式写清楚，其他都靠few-shot示例来引导，效果稳定不少。模板确实得自己调，网上现成的很难贴合你的数据分布，建议先拿100个真实问题做A/B测试，比拍脑袋改强多了。推理速度的话，模板长度影响其实有限，真正吃性能的是生成长度，别把max_tokens设太大就行。

同感，这个json格式不稳的问题太真实了，我试过在prompt里加“不要输出任何多余字符”甚至用全大写强调，还是偶尔会翻车。后来我干脆在代码里加了正则匹配提取```json ```块，或者直接让模型输出markdown代码块再解析，感觉比硬用json.loads靠谱点。function calling确实稳很多，相当于把格式控制权交给api底层，不过得先定义好函数结构，对简单场景有点杀鸡用牛刀的感

我也在折腾类似的问题，版本控制那块卡了好久。目前想到的方案是给每个chunk存个版本号，查询时带上最新版本过滤，但这样检索量会翻倍。你试过用ChromaDB的metadata过滤来实现增量更新吗？比如新增文档时只改对应id的embedding，旧数据保留但打个过期标记，这样应该不用全量重建。