Poliscope如何借助Qdrant在一台服务器上实现全德国地方政治内容可搜索
内容提要
Poliscope将德国约1.1万个市镇的议会文件（议程、纪要、规划等）经OCR处理后建成统一搜索平台，覆盖约90%市镇。平台采用自托管Qdrant开源版，通过按州多租户分区、区域ID前缀索引和TurboQuant量化优化，使1.3亿向量的混合检索从20秒降至平均0.87秒，全部运行在德国一台服务器上，兼顾数据主权与小团队运维。
延伸解读
数据主权与自托管的权衡
Poliscope 选择自托管 Qdrant 开源版，核心动机是数据主权：避免美国云厂商持有索引，规避 CLOUD Act 风险。这使其能在销售中强调数据留在德国。但代价是运维责任自负，例如分片布局需团队自行调整，早期通过新建集合并切换解决。对于同样重视数据管辖的团队，这提供了一个可参考的路径，但需评估自身运维能力。
多租户与前缀索引的过滤优化
文章显示，按州划分 12 个租户，使查询能提前丢弃最多 80% 的语料；利用德国行政 ID 的层级前缀特性，单次前缀匹配即可覆盖“某地区内全部”，将单镇搜索从 6-10 秒降至 0.3-0.8 秒。这提示：当数据天然具有地理或组织层级时，将过滤条件下推至向量搜索前，比单纯优化向量索引更有效。
量化压缩的渐进式收益
Poliscope 从 2-bit 二值量化切换到 1.5-bit TurboQuant，索引从 45.9 GiB 降至 35.1 GiB，P50 延迟从 16.8 ms 降至 11.7 ms，Recall@10 从 69.5% 提升至 75.1%；再将磁盘原始向量从 float32 转为 turbo4，磁盘占用从 1174 GiB 减至 531 GiB，P95 延迟从 23.9 ms 降至 12.5 ms，召回几乎不变。这表明量化调优可同时改善存储、延迟和召回，但需逐项测量。
小团队运维单节点的现实约束
整个搜索栈运行在一台 256 GB 内存的 Hetzner 裸金属服务器上，数据库与 API 共享同一机器。团队能自主决定核心分配和回填调度，但分片布局等决策也需自己承担。文章提到，搜索只是平台一部分，主要工程精力在于可靠爬取数千个门户。这提醒：自托管搜索的可行性不仅取决于软件，还取决于团队能否将搜索运维控制在有限范围内。
Q&A
Poliscope 是什么？它主要解决什么问题？
Poliscope 是一个让德国地方政治数据可搜索的平台。它抓取德国约 1.1 万个市镇的议会文件（议程、纪要、规划等），经 OCR 处理后放入统一搜索框，使用户能跨所有市镇搜索地方政治内容。
Poliscope 为什么选择自托管 Qdrant 而不是托管向量数据库服务？
主要出于数据主权和 jurisdiction 考虑：Poliscope 希望数据留在德国、由自己控制，避免美国厂商持有索引及受美国 CLOUD Act 影响。此外，自托管便于团队根据实际搜索模式调优，且 Qdrant 开源版能满足混合检索、分层过滤和结果分组等需求。
Poliscope 如何将搜索延迟从 20 秒降到 1 秒以内？
通过三项主要优化：1）按州进行多租户分区，查询时可提前丢弃多达 80% 的语料；2）在区域层级 ID 上建立前缀索引，快速覆盖“某地区内所有内容”；3）使用 TurboQuant 量化（1.5 位内存索引和 turbo4 磁盘原始向量），减少存储并提升召回。最终端到端平均搜索耗时 0.87 秒。
Poliscope 的搜索查询是如何处理的？
查询解析器支持混合模式下的 OR 子查询，以及关键词模式下的 AND、NOT 和精确短语。混合预取同时运行 BM25 和稠密搜索（稠密侧使用 1.5 位 TurboQuant 索引并以 3 倍过采样对 turbo4 原始向量重打分），用 DBSF 融合结果，再按会议或提案分组，最后用 Jina 交叉编码器重排序。每个结果都带有 PDF 页码范围，可深链到源文档对应页。
Poliscope 的整个系统运行在什么硬件上？团队规模如何？
Qdrant 1.19 开源版以单节点运行，一个集合包含 1.3 亿个点，分布在 12 个分片，部署在德国一台 Hetzner 裸金属服务器上，内存 256 GB，数据库和 API 共享同一台机器。团队规模很小，没有专门的搜索团队，搜索只是平台的一部分。
Poliscope 未来有哪些扩展计划？
数据方面，目前从 2024 年 1 月开始，将与研究中心合作回溯至 2016 年，语料将扩大数倍。基础设施方面，当集合增长超过单机容量时，计划增加第二个节点并跨节点分片，届时会重新评估自托管与托管服务的选择。检索方面，团队已开始测量每次配置变更的召回率，并考虑使用更短的稠密向量。
