直接回答：自建 GEO 平台的架构可以概括为四层——内容层（要优化什么）、采集与分析层（怎么获取和判断）、服务层（对外提供什么能力）、存储与运维层（怎么跑得住）。技术选型的核心原则是：在满足需求的前提下，尽量减少需要长期维护的组件数量。
先明确要解决的问题
我在动手之前列了一张需求清单，按优先级排：
- 给定一批主题词和问题集，能自动检查目标站点是否被 AI 引用。
- 能抓取并解析目标站点的内容，判断它是否具备被引用的条件。
- 能把我自己的内容资产结构化，方便复用和改写。
- 能定期出报告，告诉我"哪些页面被引用了、哪些没有、原因是什么"。
- 全流程跑在一台服务器上，不引入需要专职运维的组件。
第 5 条是硬约束。它直接决定了后面所有的技术选型。
整体架构
四层各自的职责：
| 层 | 负责什么 | 关键点 |
|---|---|---|
| 内容层 | 主题词库、问题集、内容资产、模板规范 | 数据质量决定整个平台的上限 |
| 采集与分析层 | 抓取、切分、向量化、引用采样 | 最耗时、最容易出稳定性问题 |
| 服务层 | 诊断 API、任务调度、报告生成 | 保持无状态，方便重启和扩容 |
| 存储与运维层 | 数据库、对象存储、容器编排 | 组件越少越好 |
关键选型一：为什么是 pgvector 而不是专用向量库
这是被问得最多的一个问题。先看数据：
| 方案 | 部署成本 | 100 万片段检索耗时 | 运维复杂度 |
|---|---|---|---|
| pgvector（HNSW） | 随 Postgres 一起部署 | 约 20-60 ms | 低，复用现有数据库 |
| 专用向量库 | 独立集群 | 约 10-30 ms | 高，需单独备份、监控、扩容 |
在 100 万条以内，两者的延迟差距对交互式体验没有实质影响。而省掉一套独立集群，意味着少一套备份策略、少一套监控告警、少一个半夜可能挂掉的组件。
真正需要专用向量库的临界点，通常是千万级向量加上高并发检索。 中小型 GEO 平台很难触达这个量级。
性能够用的判断也可以量化：单次检索延迟在 100 ms 以内、写入吞吐能跟上增量更新、备份和恢复流程能在半小时内跑完——三条都满足，就没有换的必要。
关键选型二：服务层怎么切
服务层我切成三个独立进程，而不是做成一个大单体：
1 | geo-diagnose 无状态 HTTP 服务 ← 接收 URL / 站点，返回诊断结果 |
切分的依据是变更频率：诊断逻辑每周都在调，调度周期很稳定，报告格式经常改。放在一起会导致每次改报告都要重启整个服务。
三者通过数据库和消息表通信，不引入独立的消息队列——对当前规模来说，一个带状态的表加轮询完全够用，而且更容易排查问题。
关键选型三：抓取环节的取舍
抓取是整个平台最不可控的部分。我的处理方式：
| 问题 | 处理方式 |
|---|---|
| 目标站点屏蔽爬虫 | 尊重 robots.txt，不绕过；改用手动提交 URL |
| 动态渲染页面 | 优先解析 HTML；确实需要渲染时用无头浏览器，但限制并发 |
| 频繁重抓浪费资源 | 按 last-modified 与内容哈希做增量判断 |
| 大量超时拖慢队列 | 单域名并发限制为 2，超时 15 秒，失败三次降级跳过 |
一个实测数据：在 4 核 8G 的 ECS 上，单进程抓取 200 个站点的首页与核心页面，总耗时约 12 分钟，峰值内存 900 MB。瓶颈在网络带宽而不是 CPU。
存储与运维
1 | PostgreSQL 16 + pgvector 结构化数据 + 向量索引 |
整套东西用一份 docker-compose.yml 管起来，docker compose up -d 就能跑。备份用一个 nightly 的 pg_dump 加对象存储同步，恢复演练每季度做一次。
这套架构的边界
坦白说，这套设计有几处明确的取舍，如果规模变化需要重新考虑：
- 数据量超过 500 万片段，需要把向量检索拆出去，或者对数据分片。
- 同时监测的站点超过 20 个，需要把调度从单进程改为分布式队列，否则任务会排队。
- 需要实时反馈（用户点一下等 3 秒出结果），需要给诊断接口单独做缓存层，当前是分钟级。
写清楚边界比写清楚优势更有用——知道什么情况下它会失效，才能判断它适不适合你的场景。
常见问题（FAQ）
为什么不用专用的向量数据库？
在数据量小于 100 万条片段时，pgvector 的性能和专用向量库差距不明显，但省掉了一整套运维成本。真正需要专用向量库的临界点通常是千万级向量加上高并发检索，中小型 GEO 平台很难触达。
一台 4 核 8G 的服务器能撑住吗？
能。本站的平台在 4 核 8G 的阿里云 ECS 上运行，覆盖约 200 个站点的抓取与 50 万条片段的检索，日常 CPU 占用在 20% 以下。瓶颈通常出现在抓取阶段的网络带宽，而不是计算。
平台需要接入多少个大模型？
建议至少两个。一个用于便宜、量大的内容分析任务，另一个用于质量要求高的判断任务。同时接入多个平台用于引用采样，也能避免单一模型的偏差。
下一篇
架构确定之后，最难的部分是内容采集与结构化流水线：《自建 GEO 平台（二）：内容采集与结构化流水线》。
如果你也在搭类似的东西，或者在选型上纠结，欢迎到留言板聊聊——我很想知道别人是怎么权衡的。
