德国市政数据平台Poliscope：利用行政区划层级编码，单服务器实现1.3亿向量亚秒级搜索

德国行政区划编码有一个工程上极为有利的特性：每个下级实体的ID都以父级ID为前缀。Poliscope的联合创始人兼CTO Kolja Martens利用这一结构，在Qdrant向量数据库中按州建立租户分区，使查询在进入向量搜索之前就能丢弃最多80%的语料。经过租户分区、前缀索引和量化迁移三项优化叠加，当前1.3亿向量集合的Qdrant查询P50延迟降至8.5毫秒，端到端平均0.87秒；而最初版本在约7000万点、未经调优时单次搜索曾高达20秒。

Poliscope做的事情是：爬取德国约4800个市政议会信息系统（德语称Ratsinformationssystem），覆盖约90%的德国市政体和98%的人口。这些系统运行在十几种互不通信的软件产品上，发布议程、会议纪要、提案和规划文件——正是人们最直接感受到的政治层：风电场选址、新建学校、公交线路是否保留。Poliscope对4.3 TB的PDF做光学字符识别，将结果分块嵌入为1536维向量，存入Qdrant。目前库中有1.3亿个点，其中1.17亿是文档块，每月新增约2万个会议。

Martens列出了三项关键优化，每项都在生产语料上实测。第一项是租户分区：德国16个州被归为12个租户，与集合的12个分片一一对应。由于查询几乎总是携带地区条件，向量搜索开始前就能排除80%的数据，典型词查询从1315毫秒降至235毫秒。第二项是前缀索引：利用行政ID的严格层级结构，一个前缀匹配就能覆盖这个区内的所有实体，替代了系统中最慢的过滤器，单城镇搜索从6到10秒降至0.3到0.8秒。第三项是量化迁移：2026年9月26日从2位二值量化切换到1.5位TurboQuant，仅改配置无需重新入库，内存索引从45.9 GiB缩至35.1 GiB，P50延迟从16.8毫秒降至11.7毫秒，召回率@10反而从69.5%升至75.1%。两天后又将磁盘原始向量从float32迁移到turbo4类型，磁盘占用从1174 GiB降至531 GiB，P95延迟从23.9毫秒降至12.5毫秒，召回率基本不变。

选择自托管不只是为了成本。Martens明确要求欧盟境内的纯数据栈，不接受美国供应商持有索引，不暴露于美国《云法案》（CLOUD Act）的域外管辖。数据主权出现在Poliscope自己的销售对话中，美国超大规模云服务商的托管区域无法满足这一要求。最终部署是一台位于德国的Hetzner裸金属服务器，256 GB内存，运行Qdrant 1.19开源版，单节点12分片，数据库和API共享同一台机器。Martens说，团队自己决定哪些核心回答查询、哪些运行优化器，大型回填任务围绕生产流量调度而非围绕供应商的限制。

所有性能数据均为Poliscope自测，通过Qdrant官方博客发布，尚无独立复现。Poliscope的数据从2024年1月开始，与研究中心的合作将把覆盖期推回2016年，届时语料量将成倍增长。Martens计划在数据超出单机容量时增加第二个节点并重新评估自托管与托管的取舍。团队刚开始对每次配置变更测量召回率，并考虑缩短稠密向量维度，因为混合检索配合BM25在1536维下尚未出现已知漏检。Martens总结说："每一个我们遇到的扩展问题都有一个旋钮可以调，而且那个旋钮的文档写得很好。"

查询路径上，爬虫从约4800个门户拉取会议、议程项、提案和PDF，PDF经GPU机器上的视觉模型逐页转为Markdown，再由工作进程分块、以1536维嵌入并写入Qdrant，同时用Qdrant内置BM25生成稀疏向量。查询时混合预取同时运行BM25和稠密搜索，稠密侧从1.5位TurboQuant索引召回、以3倍过采样对turbo4原始向量重打分，再用分布融合合并结果，最后经Jina多语言交叉编码器重排。每条命中携带PDF页码范围，可深链到源文件对应页面。

Poliscope最初用一台服务器解决了一个原本靠实习生逐个打开门户才能完成的监控问题。Martens说，现在一个搜索框就能看到全国哪些议会在上周讨论过你的议题，市政层面的监控从几乎不可能变成了像Google搜索一样简单。