后端工具选型别只比较参数选向量数据库或检索服务时README 上的 QPS、延迟和索引类型只能说明它在某组测试条件下的表现。它们不能直接回答现有服务怎样传向量、过滤条件能否正确下推、峰值并发会不会挤满连接池、备份和版本升级由谁负责。真正的选型要放回当前语言、数据规模和运维能力里判断。以 Node.js 服务为例数据库端很快不代表整个请求很快。JSON 编解码、大数组处理、日志格式化、同步加密或 SDK 中的 CPU 密集操作都可能占用事件循环。问题不一定由某个中间件“导致”但评估时需要测到客户端这一侧才能知道瓶颈在哪。先明确检索的真实工作负载准备测试前收集典型和边界请求向量维度、top-k、过滤字段、租户隔离、索引更新频率、输入数据类型和可接受的召回/延迟取舍。只测无过滤的单条相似检索通常会高估生产表现真实查询常常还要做权限过滤、时间范围筛选或结果融合。指标也不该只有平均延迟。应记录端到端耗时、队列等待、数据库耗时、连接池等待、Node 堆内存、事件循环延迟和错误类别。用统一的请求 ID 连接这些记录避免把网络、序列化和数据库耗时混成一个数字。import { monitorEventLoopDelay } from node:perf_hooks const lag monitorEventLoopDelay({ resolution: 20 }) lag.enable() export function eventLoopSnapshot() { return { meanMs: Number(lag.mean) / 1e6, p99Ms: Number(lag.percentile(99)) / 1e6, } }事件循环延迟是诊断线索不是单独的通过标准。采样周期、GC、机器负载和日志量都会影响它应同负载测试的时间线一起看。SDK 与连接模型需要实际压测评审客户端 SDK 时要看它是否复用连接、是否支持请求取消、超时发生后如何处置连接、是否给并发请求施加上限。无界 Promise 堆积会先消耗本地堆内存再把问题传给远端因此入口限流和连接池队列同样重要。向量的归一化、转换和序列化是否需要放进 worker取决于实际 CPU 占比和吞吐。不要先假设“所有数组计算都会阻塞”就增加线程池worker 通信和对象复制也有成本。先用 profiling 找出热路径再对高成本且可并行的处理做隔离并设置队列上限和超时。查询参数必须参数化。把向量拼成字符串有时是驱动要求但过滤值、表名或排序字段不能因此改为字符串拼接。还要限制top-k和向量维度避免一个异常请求产生不成比例的序列化和查询负担。专用库与现有基础设施各有边界使用 PostgreSQL 加 pgvector 可能减少运维面并便于同关系数据做过滤和事务专用向量数据库则可能在特定索引、分片或检索功能上更合适。二者没有对所有规模都成立的胜负关系。应把备份恢复、监控、权限模型、数据迁移、故障演练和团队熟悉度一起放进成本表。兼容性也要验证完整路径导入、建索引、写入、过滤检索、重建索引、备份恢复和客户端升级。不要只在空库上跑 benchmark数据分布、删除和更新会影响索引行为生产前至少要用代表性样本演练一次。为失败路径准备降级检索超时后系统是返回较少结果、走关键字搜索、排队还是明确告知暂不可用应由产品场景决定。重要的是不要在超时后无限重试也不要把没有检索结果伪装成模型已经验证过的答案。熔断、超时和缓存要有可观测的命中原因方便判断是后端能力不足还是输入发生了变化。选型最后应留下可复跑的决策记录测试版本、硬件、数据规模、负载形状、结果与已知限制。参数表可以作为参考但只有在目标服务里测过完整链路、失败路径和维护成本比较才真正能帮助做决定。