要先把缓存做到和索引差不多大
Databricks 10 月 15 日的工程博文用两个负载说明 Lakebase 检索该配多大计算。页面时间是世界时 00:06，北京时间 08:06。一个负载是内部应用 Slide Hub，大约 700 份内部演示、2.3 万条幻灯片，检索给人和给智能体的 MCP 用。另一个是 MIRACL 英文维基语料的子集，测到 100 万、200 万和 400 万条。
他们把缓存大小除以向量索引大小叫缓存比。斜分布查询在比值 0.07 时大约 45% 的页在缓存里，0.57 时大约 86%，1.14、也就是索引刚好放得下时大约 97%。均匀查询再低几个点，因为它几乎不重复。博文据此说，缓存大约和索引一样大时，大约 95% 到 98% 的页不用再读存储。
[1]
少取候选，前十名大体还在
Slide Hub 原来每个方法取 1000 个候选。收到 200 个时，冷缓存 387 毫秒，重复查询 11.7 毫秒，前 10 条里有 90.5% 和 1000 候选时相同，读到的页大约是 1000 候选的三分之一。40 个候选时，前 10 重叠掉到 74.5%。他们现在按 200 个候选交付。
同一云区域里，200 候选的冷检索端到端 2.9 秒，其中大约 1 秒在等计算从零唤醒；重复查询 40 毫秒。
[1]0.02 美元是这一次 14 分钟
一次同区域加压跑了 14 分钟，标价 0.13 美元：应用 0.11 美元，Lakebase Postgres 0.02 美元。计算在 0.5 到 1 个计算单位之间自动伸缩，用了 0.21 个计算单位小时。最多到 1000 个用户时，这一轮送出 109602 次请求，博文写没有错误。
他们建议生产环境把下限放在 0.5 个计算单位，而不是缩到零。按标价大约每月 31 到 40 美元，用来避开大约 1 秒的唤醒和空缓存。Slide Hub 自己因为能接受闲置后的慢第一次检索，生产库仍会缩到零。Lakebase 大约占这个内部应用 30 天账单的 1%。
[1]默认设置找回大约四分之三
索引是近似的。Recall@10 是精确最近的 10 条里，索引也能返回的比例。默认探针数下，100 万、200 万、400 万条分别是 0.74、0.75、0.75。400 万条上，默认 109 个探针用 3 毫秒拿到 0.74，2000 个探针用 49 毫秒拿到 0.95。
用质量模式建索引后，同样的默认探针在 3 毫秒里到 0.80，2000 个探针大约同样时间到 0.97。400 万条、16 个计算单位的构建花了 52 分钟。博文写，召回取决于数据和嵌入模型，探针数要按自己的应用再量。
[1]