自研 GEO 系统实战：从架构设计到“一键投喂”多平台 AI 大模型

一、为什么我要专门做一套 GEO 系统？

过去十几年，我们习惯讨论的是 SEO：怎么让自己的页面在搜索结果里排到前面。

但这两年明显的变化是------用户越来越习惯直接问大模型："有什么推荐？"、"哪个产品更适合我？"，而不是自己翻搜索结果页。

当入口从"搜索结果列表"变成"AI 直接给出的答案"，传统的 SEO 优化就不够用了：

页面排名高，不代表大模型一定会引用你的内容。
文章很多，不代表模型真的记住了你的品牌和产品。
更别说如何让模型在比较不同方案时"优先想起你"。

这就是我做 GEO（Generative Engine Optimization，生成式引擎优化）系统的原因：

用工程化方式，持续、可控地给大模型"投喂"企业的知识资产，让它在回答用户问题时，更有机会引用我们的品牌、产品和解决方案。

二、总体设计思路：把 GEO 系统当成一个"内容操作系统"

我不把 GEO 系统当成一个简单的发文工具，而是按"资产 → 语义 → 生成 → 投喂 → 监测 → 反馈"的闭环来设计。整体可以拆成五层：

内容资产层

沉淀品牌介绍、产品参数、案例、FAQ、技术文档等原始资料，统一管理。
语义加工层

将长文档切片、清洗，抽取实体（品牌、产品、行业、问题），构建主题簇和问答库，把企业知识转成适合模型理解的语义块。
内容生成层

结合模板、事实库和大模型能力，生成不同形态的投喂内容：技术文章、问答对、使用案例、平台短内容等。
渠道分发层

适配不同站点和平台的发布规则，实现"一套内容，多渠道投放"：技术社区、博客、资讯媒体、本地站点等。
效果监测层

定期向主流大模型提问，抓取答案，分析是否出现自家品牌和产品、出现频率、位置和叙事方式，再把结果反哺到下一轮优化。

我更喜欢用一句话概括：这不是一个工具，而是一套围绕企业知识资产的自动化投喂和观测系统。

三、技术栈选择：为什么我用 Python + 队列 + 检索

从落地效率和生态来看，技术栈我选的是：

前端管理后台：Vue 3 / React
后端 API：FastAPI / Flask
异步任务：Celery / RQ
消息队列：Redis / RabbitMQ
数据库：PostgreSQL
检索：Elasticsearch + 向量检索（如 pgvector / Milvus 等）
文档解析：BeautifulSoup / pdfplumber / trafilatura
模型调用：兼容 OpenAI 风格的接口或自建网关

原因很简单：

Python 在文本处理、Embedding、RAG 场景下工具齐全、社区成熟。
队列非常适合"批量生成、批量分发、批量回测"这种典型异步任务。
结构化数据库负责事实与关系，向量库负责语义召回，两者组合能更好支撑 GEO 的"事实可靠 + 语义相关"。

四、数据库设计：我实际用的 8 张核心表

下面是我生产环境里基本都会有的八张核心表，你可以按自己需要做精简或扩展。

1. 品牌资产表：`brand_assets`

复制代码

CREATE TABLE brand_assets (
    id BIGSERIAL PRIMARY KEY,
    brand_name        VARCHAR(128) NOT NULL,
    asset_type        VARCHAR(64)  NOT NULL,   -- intro/case/faq/spec/news
    title             VARCHAR(255),
    source_text       TEXT,
    source_url        TEXT,
    lang              VARCHAR(16)  DEFAULT 'zh-CN',
    status            VARCHAR(32)  DEFAULT 'active',
    created_at        TIMESTAMP    DEFAULT NOW(),
    updated_at        TIMESTAMP    DEFAULT NOW()
);

2. 知识切片表：`knowledge_chunks`

复制代码

CREATE TABLE knowledge_chunks (
    id BIGSERIAL PRIMARY KEY,
    asset_id      BIGINT REFERENCES brand_assets(id),
    chunk_index   INT,
    chunk_text    TEXT NOT NULL,
    token_count   INT,
    embedding_id  VARCHAR(128),
    topic_label   VARCHAR(128),
    created_at    TIMESTAMP DEFAULT NOW()
);

实体表：entities

CREATE TABLE entities (
id BIGSERIAL PRIMARY KEY,
entity_name VARCHAR(255) NOT NULL,
entity_type VARCHAR(64) NOT NULL, -- brand/product/industry/problem
alias JSONB,
metadata JSONB,
created_at TIMESTAMP DEFAULT NOW()
);
问答表：qa_pairs

CREATE TABLE qa_pairs (
id BIGSERIAL PRIMARY KEY,
question TEXT NOT NULL,
answer TEXT NOT NULL,
related_entity_ids JSONB,
source_chunk_ids JSONB,
confidence NUMERIC(5,2),
created_at TIMESTAMP DEFAULT NOW()
);
内容生成任务表：content_jobs

CREATE TABLE content_jobs (
id BIGSERIAL PRIMARY KEY,
job_type VARCHAR(64) NOT NULL, -- article/faq/post/case
target_keyword VARCHAR(255),
platform VARCHAR(64),
prompt_version VARCHAR(64),
status VARCHAR(32) DEFAULT 'pending',
result_content_id BIGINT,
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);

6. 生成内容表：`generated_contents`

复制代码

CREATE TABLE generated_contents (
    id BIGSERIAL PRIMARY KEY,
    title             TEXT,
    content_markdown  TEXT,
    summary           TEXT,
    content_type      VARCHAR(64),
    platform_style    VARCHAR(64),
    quality_score     NUMERIC(5,2),
    duplicate_score   NUMERIC(5,2),
    created_at        TIMESTAMP DEFAULT NOW()
);

发布记录表：publish_records

CREATE TABLE publish_records (
id BIGSERIAL PRIMARY KEY,
content_id BIGINT REFERENCES generated_contents(id),
platform VARCHAR(64),
publish_account VARCHAR(128),
external_post_id VARCHAR(255),
publish_status VARCHAR(32),
response_payload JSONB,
published_at TIMESTAMP
);
AI 观测日志表：ai_observation_logs

CREATE TABLE ai_observation_logs (
id BIGSERIAL PRIMARY KEY,
platform VARCHAR(64),
query_text TEXT NOT NULL,
answer_text TEXT,
brand_hit BOOLEAN,
mention_score NUMERIC(5,2),
citation_score NUMERIC(5,2),
rank_label VARCHAR(32),
observed_at TIMESTAMP DEFAULT NOW()
);

这八张表基本支撑了：

资产沉淀（assets / chunks / entities / qa）
内容生产和任务管理（jobs / contents）
渠道发布和状态记录（publish）
AI 回答观测与分析（observation）

五、内容生成服务：不是"直接调用模型"那么简单

生成内容这一步，我的原则是：召回事实 → 构建大纲 → 调用模型生成 → 质量评估 → 必要时再修正。

Python 伪代码示例

复制代码

class ContentGenerator:
    def __init__(self, retriever, llm_client, scorer):
        self.retriever = retriever      # 检索知识切片
        self.llm_client = llm_client    # 调用大模型
        self.scorer = scorer            # 质量评分器

    def generate_article(self, keyword: str, brand: str, platform: str):
        # 1. 从知识库召回相关事实
        docs = self.retriever.search(keyword=keyword, top_k=12)
        facts = [doc["text"] for doc in docs]

        # 2. 构建文章大纲
        outline = [
            f"{keyword}是什么",
            f"{keyword}为什么值得单独做成系统",
            f"{keyword}的整体架构设计",
            f"{keyword}的核心模块与代码细节",
            f"{keyword}在实际业务中的效果评估"
        ]

        # 3. 调用模型生成草稿
        prompt = self._render_prompt(keyword, brand, platform, outline, facts)
        draft = self.llm_client.generate(prompt)

        # 4. 做质量评估
        score = self.scorer.evaluate(draft, facts)

        # 5. 如果事实覆盖率不够，再修正一轮
        if score["fact_score"] < 0.8:
            draft = self._repair(draft, facts)

        return {
            "outline": outline,
            "content": draft,
            "score": score
        }

    def _render_prompt(self, keyword, brand, platform, outline, facts):
        return f"""
你是一名技术作者，请围绕 GEO 系统写一篇文章，
面向平台：{platform}，品牌：{brand}，
核心关键词：{keyword}。

请按以下大纲写作：
{outline}

必须优先使用以下事实和资料：
{facts}
"""

六、多平台分发：用适配器模式解耦不同渠道

不同平台的接口和风格差异很大，用适配器模式会省很多坑。

基础适配器抽象类

复制代码

from abc import ABC, abstractmethod

class BasePublisher(ABC):
    @abstractmethod
    def publish(self, content: dict) -> dict:
        """发布内容，返回平台的响应信息"""
        pass

    @abstractmethod
    def update(self, post_id: str, content: dict) -> dict:
        """更新已发布内容"""
        pass

这样一来，一键投喂的流程大致就是：

前端勾选渠道矩阵（比如 CSDN、博客、公司官网）。
后端为每个渠道创建一个 content_jobs 任务。
异步任务调用 ContentGenerator 生成内容，再调 PublishDispatcher 发布。
发布结果写入 publish_records 表，前端可查看每个渠道的发布状态。

七、AI 回测服务：让系统持续知道"模型现在怎么说你"

很多人做 GEO 停留在"发出去就完事"的阶段，其实最关键的是观测。

回测服务的三个核心指标

是否出现品牌名或产品名（品牌命中率）。
是否引用了我们投喂过的内容或结论（引用率）。
在推荐列表或比较结果中的位置（排序情况）。

Python 伪代码示例

复制代码

class AiObserver:
    def __init__(self, llm_clients: dict, brand_terms: list):
        self.llm_clients = llm_clients  # {"deepseek": client1, "platformX": client2}
        self.brand_terms = brand_terms  # ["某品牌", "某产品", "某系统"]

    def observe(self, questions: list):
        results = []
        for platform, client in self.llm_clients.items():
            for q in questions:
                answer = client.ask(q)
                hit = any(term in answer for term in self.brand_terms)
                mention_score = self._mention_score(answer)
                results.append({
                    "platform": platform,
                    "question": q,
                    "answer": answer,
                    "brand_hit": hit,
                    "mention_score": mention_score
                })
        return results

    def _mention_score(self, answer: str) -> float:
        score = 0.0
        for term in self.brand_terms:
            if term in answer:
                score += 1.0
        return score

回测结果会写入 ai_observation_logs 表，然后我通常会做一个可视化看板：

不同平台、不同问题的命中率曲线。
最近一次投喂后的变化趋势。
哪些问题目前完全没提到我们，需要加强内容覆盖。

八、异步任务与调度：为什么"一键投喂"一定要走队列

GEO 系统里最重的三个动作是：

批量解析原始资料。
批量生成文章、问答和内容。
批量向不同大模型发起观测请求。

如果用同步接口做，很容易出现：请求超时、前端一直转圈、接口偶尔挂掉。

所以我几乎所有关键流程都放到任务队列里，通过 Celery 来调度。

Celery 任务示例：生成并发布

复制代码

from celery import Celery

celery_app = Celery(
    "geo_tasks",
    broker="redis://localhost:6379/0",
    backend="redis://localhost:6379/1"
)

@celery_app.task
def generate_and_publish(keyword, brand, platform):
    generator = build_generator()   # 构造 ContentGenerator
    dispatcher = build_dispatcher() # 构造 PublishDispatcher

    article = generator.generate_article(keyword, brand, platform)
    content = {
        "title": f"{keyword}实战解析",
        "body": article["content"],
        "tags": [keyword, "GEO", "AI搜索优化"]
    }
    result = dispatcher.dispatch(platform, content)
    return result

后端返回一个 job_id，所有后续过程都在后台自动完成，前端通过 GET /api/jobs/{job_id} 看最新状态即可。

九、内容质量控制：避免系统变成"批量制造垃圾"的机器

GEO 爆火之后，一个现实问题是，市场上开始出现大量低质量甚至错误的"投喂内容"。

如果我们只做"机器多写点文，多发一点链接"，长期来看其实会伤害品牌信誉。

所以我在系统里加了一个简单的质量评分器，至少从三个维度去衡量：

事实覆盖度：生成结果是否覆盖了我们知识库里最重要的事实点。
重复度：和历史内容以及同批次内容相比，有没有过度相似或洗稿。
可读性：句子是否通顺、结构是否清晰、对开发者是否友好。

简单的评分器示例

复制代码

class QualityScorer:
    def evaluate(self, draft: str, facts: list):
        fact_score = self._fact_coverage(draft, facts)
        duplicate_score = self._duplicate_check(draft)
        readability_score = self._readability(draft)

        final_score = (
            0.5 * fact_score +
            0.3 * readability_score +
            0.2 * (1 - duplicate_score)
        )

        return {
            "fact_score": fact_score,
            "duplicate_score": duplicate_score,
            "readability_score": readability_score,
            "final_score": final_score
        }

    def _fact_coverage(self, draft: str, facts: list) -> float:
        covered = sum(1 for f in facts if f[:50] in draft)
        return covered / max(len(facts), 1)

    def _duplicate_check(self, draft: str) -> float:
        # 这里可以接相似度模型或现有检测服务
        return 0.2

    def _readability(self, draft: str) -> float:
        # 粗略以句长、分段、标点等计算
        return 0.85

对于质量评分较低的内容，可以直接标红不允许自动发布，必须走人工审核，避免系统在无意中制造"AI 垃圾"。

十、总结：把 GEO 当成基础设施，而不是短期投机

从我的实践来看，如果把 GEO 当成一个短期流量工具，很容易落到"批量发文、批量铺链接"的老路上。

真正值得长期投入的，是把它当成企业在 AI 时代的基础设施：

知识资产被持续结构化和语义化。
内容生成和分发流程尽可能自动化，同时保留关键节点的人工审核。
AI 回答观测变成例行任务，而不是偶尔"去问一下看看有没有提到我们"。
每一次发布、每一次观测，都能反过来优化下一轮的策略和系统。

从这个角度看，GEO 系统的核心竞争力并不在于"我能调用哪个大模型"，而在于你是否有能力把真实的业务知识，用工程化方式转成 AI 持续引用的"语义基础设施"。

自研 GEO 系统实战：从架构设计到“一键投喂”多平台 AI 大模型

一、为什么我要专门做一套 GEO 系统？

二、总体设计思路：把 GEO 系统当成一个"内容操作系统"

三、技术栈选择：为什么我用 Python + 队列 + 检索

四、数据库设计：我实际用的 8 张核心表

1. 品牌资产表：brand_assets

2. 知识切片表：knowledge_chunks

6. 生成内容表：generated_contents

五、内容生成服务：不是"直接调用模型"那么简单

Python 伪代码示例

六、多平台分发：用适配器模式解耦不同渠道

基础适配器抽象类

七、AI 回测服务：让系统持续知道"模型现在怎么说你"

回测服务的三个核心指标

Python 伪代码示例

八、异步任务与调度：为什么"一键投喂"一定要走队列

Celery 任务示例：生成并发布

九、内容质量控制：避免系统变成"批量制造垃圾"的机器

简单的评分器示例

十、总结：把 GEO 当成基础设施，而不是短期投机

1. 品牌资产表：`brand_assets`

2. 知识切片表：`knowledge_chunks`

6. 生成内容表：`generated_contents`