微软将 OpenAI 列为竞争对手的 SEC 文件全解：Agentic RAG 知识图谱如何沉淀竞争情报

微软将 OpenAI 列为竞争对手的 SEC 文件全解：Agentic RAG 知识图谱如何沉淀竞争情报

【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents

本文以 agentic-rag-knowledge-graph 项目内置竞争情报语料 doc5_microsoft_openai_tensions.md 为主体，完整解析 2024 年 8 月微软在 10-K 年报中把 OpenAI 列为竞争对手这一事件的竞争领域、合作背景、张力来源与财务影响，并结合该项目的摄取管道与图数据库源码，说明这份"微软-OpenAI 关系"文档如何被实体抽取、切块入库，最终变成可被 Agent 用自然语言查询的结构化知识资产。

一、核心事实：130 亿美元合作之下，微软把 OpenAI 写进了"竞争对手"

据文档记载（来源标注为 The Information，2024 年 8 月 1 日报道），微软在一项监管文件中将 OpenAI 列为 AI 与搜索市场的竞争对手，尽管双方维持着 130 亿美元规模的战略合作伙伴关系。这一披露来自微软的 10-K 年度报告，标志着两家公司的关系出现公开化的紧张信号。

文档列出了 10-K 中将 OpenAI 列为竞争对手的四个具体领域，这是理解竞争边界的关键：

值得注意的是第四行：微软一边把 OpenAI 的"定制 AI 模型"视为对 Azure OpenAI Service 的竞争，一边自身产品又深度依赖 OpenAI——这种"既合作又竞争"（co-opetition）的状态，正是后文张力分析的主线。

1.1 合作背景：从 10 亿美元到 130 亿美元的注资轨迹

文档给出了双方关系的时间线，这也是知识图谱中典型的"时间序列事实"（temporal facts）：

• 2019 年：10 亿美元初始投资；
• 2021 年：多年期合作伙伴协议；
• 2023 年：100 亿美元投资（文档记载对应 OpenAI 49% 股权）；
• 2024 年：额外 30 亿美元承诺。

文档还特别提到：尽管投资规模巨大，该 partnership 中包含日落条款（sunset clauses），允许任一方在特定条件下退出。这一条款细节解释了为何双方在监管文件中需要明确竞争关系——合作并非不可解除，竞争定位是退出机制的前置条件。

二、竞争张力的三大来源

文档将紧张关系归纳为三类结构性冲突，每一类都对应双方产品线的正面重叠。

2.1 搜索市场重叠

OpenAI 的 ChatGPT 搜索功能直接挑战 Bing——一个被文档描述为"十余年来在搜索市场落后于 Google"的产品。据文档引用微软内部消息源，微软方面担忧 ChatGPT 会侵蚀（cannibalize）Bing 的使用量。从竞争角度看，这里存在双重矛盾：微软向 OpenAI 注资换取的搜索增强能力，反过来削弱了微软原有的核心流量入口。

2.2 企业 AI 服务竞争

文档指出 OpenAI 的企业业务日益与 Azure AI 服务正面竞争，具体体现在三个层面：

• 定制模型训练：与 Azure Machine Learning 直接竞争；
• API 服务：构成对 Azure OpenAI Service 的替代选项；
• 企业支持：双方在专业服务（professional services）上竞争。

2.3 产品集成分歧

围绕 ChatGPT 在微软产品中的集成，双方存在具体分歧：

• Windows 集成：因竞争顾虑而延迟；
• Office 集成：仅限于特定 Copilot 功能；
• Azure 优先级：OpenAI 在探索多云策略，降低对 Azure 的单一依赖。

这三点分歧共同指向一个方向：OpenAI 在主动稀释对微软基础设施的绑定程度。

三、行业背景、双方回应与云资源多元化

文档把这一竞争定位放在更宽的行业趋势中解读：

• 合作复杂性：大型科技公司越来越多地"同时竞争又合作"；
• AI 市场演变：快速增长催生出大量重叠的产品类别；
• 监管审视：AI 市场集中度引发反垄断关注。

两位 CEO 的公开表态形成了对照。微软 CEO Satya Nadella 的回应是："我们在维持牢固伙伴关系的同时承认市场现实。竞争推动创新，最终惠及客户。" OpenAI CEO Sam Altman 则淡化竞争定位："我们与微软的伙伴关系依然牢固且互惠互利。随着 AI 能力扩展，市场竞争是健康且可预期的。"

但文档引用的接近 OpenAI 的消息源透露，OpenAI 正在推进云供应商多元化以降低对微软的依赖，涉及三个方向：

• Google Cloud：探索基础设施合作；
• Amazon Web Services：针对特定工作负载的试点项目；
• Oracle：评估 GPU 容量安排。

这组动作与第二节的"产品集成分歧"相互印证，构成了该文档叙事的核心逻辑链：合作条款中的日落条款 → 竞争条款的监管披露 → 云资源多元化落地。

四、财务影响：数据如何刻画"互相需要"

文档给出了双方的财务指标，是判断关系走向最硬的事实依据。

4.1 微软侧

• Azure 增长：同比 29%，部分由 OpenAI 集成驱动；
• Copilot 采用：13 万+ 组织在使用 Microsoft 365 Copilot；
• 搜索收入：ChatGPT 集成后 Bing 市场份额提升 3 个百分点。

4.2 OpenAI 侧

• 收入依赖：65% 的 API 用量运行在 Azure 基础设施上；
• 成本结构：微软提供显著的算力补贴；
• 增长轨迹：36 亿美元 ARR（年化经常性收入），同比增长 250%。

从两侧数据可以看出不对称性：微软的增长叙事中 OpenAI 是"贡献项"，而 OpenAI 的成本结构对微软是"依赖项"。谁对这段关系的容忍度更低，往往取决于哪一侧的替代成本更低——这也是文档结尾战略展望的伏笔。

五、战略展望：走向"手臂距离"的有限合作

文档引用的行业分析师判断是：双方关系将演变为手臂距离（arm's-length）合作，具体表现为三条路径：

• 技术共享：继续但更有限的集成；
• 财务安排：投资条款可能重新谈判；
• 产品开发：独立路线图加选择性协作。

文档的总结性判断是：AI 行业的合作具有快速边界漂移性——"今天的合作者可能成为明天的竞争者"。微软-OpenAI 案例被当作这一复杂性的样本。

六、当这份文档进入 Agentic RAG 知识图谱

以上事实分析完成之后，值得追问一个工程问题：如何让"微软与 OpenAI 是什么关系"这类跨实体、带时间维度的问题，可以被自然语言直接查询？这正是 agentic-rag-knowledge-graph 项目的设计目标：用 PostgreSQL + pgvector 做向量检索，用 Neo4j + Graphiti 做时序知识图谱，由 Pydantic AI Agent 在运行时自主选择检索工具。big_tech_docs目录下的 21 份大型科技公司文档（含本文主角 doc5）正是该系统自带的示例语料。

6.1 摄取管道：这份文档是如何被入库的

执行 ingest.py 的python -m ingestion.ingest后，DocumentIngestionPipeline 会对每个 markdown 文件完成五步处理：

1. 标题提取：_extract_title 扫描文档前 10 行，取第一个#开头的行——因此 doc5 的入库标题就是"Microsoft Now Lists OpenAI as Competitor Despite $13 Billion Partnership"；
2. 元数据提取：_extract_document_metadata 记录文件路径、大小、行数、词数，并支持 YAML frontmatter；
3. 语义切块：由 chunker.py 的SemanticChunker完成，默认chunk_size=1000、chunk_overlap=200（见 ChunkingConfig），优先尝试 LLM 语义切分；
4. 向量化入库：切块经嵌入模型向量化后，由 _save_to_postgres 在单个事务内写入documents与chunks表，embedding 以'[x,y,z]'字符串格式落库；
5. 图谱构建：若未开启--fast模式，则把每个切块作为"episode"送入 Graphiti。

命令行参数在 main 函数 中定义，常用组合：

# 基础摄取（含语义切块 + 知识图谱） python -m ingestion.ingest # 清空既有数据后重新摄取（会删除 chunks/documents/sessions/messages 表数据并清空图谱） python -m ingestion.ingest --clean # 快速模式：缩小切块、关闭语义切块、跳过图谱构建 python -m ingestion.ingest --chunk-size 800 --no-semantic --verbose

需要提醒的是，README 明确提示：把全部 21 份big_tech_docs文档处理进知识图谱"可能需要 30 分钟以上"，因为实体抽取与关系构建的计算开销很大。

6.2 实体抽取：这份文档恰好是规则抽取器的"命中样本"

graph_builder.py 中的GraphBuilder.extract_entities_from_chunks（L200-L269）会按公司、技术、人物、地点四类把实体写入切块元数据。从源码的实体词表看，doc5 能稳定命中相当多的预置实体：

• 公司词表（_extract_companies 含 Google、Microsoft、OpenAI、Oracle、Amazon 等约 30 家公司）：doc5 正文中的 Microsoft、OpenAI、Google（Cloud）、Amazon（Web Services）、Oracle 均在列；
• 人物词表（_extract_people）：Satya Nadella、Sam Altman 均为预置实体；
• 技术词表（_extract_technologies）："AI"等术语会被识别。

这意味着仅靠规则抽取，doc5 的每个切块元数据中就会挂上{companies: [Microsoft, OpenAI, Google, Amazon, Oracle], people: [Satya Nadella, Sam Altman], ...}这类结构化标签，为图谱中的实体归并（Microsoft—OpenAI 边、Microsoft—Azure 边、OpenAI—Azure 依赖边）提供基础信号。

6.3 图谱写入的 token 限制处理

Graphiti 通过 GraphitiClient.add_episode 写入 Neo4j，每个切块会被赋予episode_id（格式为文档源_切块序号_时间戳）和reference_time。由于 Graphiti 存在 token 上限，GraphBuilder._prepare_episode_content 会把超过 6000 字符的内容在句子边界处截断并追加[TRUNCATED]标记；add_document_to_graph 还在每个 episode 之间插入 0.5 秒延时以减轻 LLM API 压力，单个切块失败不会中断整篇文档的处理（错误计入errors列表继续）。doc5 全文约 80 行，语义切块后每块通常远低于 6000 字符阈值，因此可完整入图。

6.4 智能体如何回答"微软与 OpenAI 是什么关系"

Agent 的工具面在 agent.py 中注册，与本文主题直接相关的有四个：

工具选择策略由系统提示词控制，prompts.py 中有一条关键规则："Use the knowledge graph tool only when the user asks about two companies in the same question"（只有当问题同时涉及两家公司时才启用图谱工具）。"How is Microsoft connected to OpenAI?"恰好是双实体问题，会触发图谱路径。README 给出的 CLI 示例会话正是这个查询，Agent 组合了hybrid_search(query='Microsoft OpenAI partnership')与get_entity_relationships(entity='Microsoft')回答"130 亿美元战略合作 + 监管竞争定位"这一复合事实——本文第一至五节的所有内容（投资时间线、竞争领域、云多元化）都来自这条检索链路所组织的证据。

图谱侧的时序能力来自 Graphiti：graph_search 的结果模型 携带valid_at与invalid_at字段，get_entity_timeline 按valid_at倒序返回事实。doc5 中 2019→2021→2023→2024 的注资时间线因此可以作为"微软实体"时间轴上的节点被查询——这是纯向量 RAG 难以给出的结构化能力。

七、环境配置与复现路径

若要实际运行这套查询，按 README 的步骤配置.env即可，核心变量如下：

# Postgres（如 Neon）连接串 DATABASE_URL=postgresql://username:password@ep-example-12345.us-east-2.aws.neon.tech/neondb # Neo4j 图数据库 NEO4J_URI=bolt://localhost:7687 NEO4J_USER=neo4j NEO4J_PASSWORD=your_password # LLM 提供方（OpenAI / Ollama / OpenRouter / Gemini 可切换） LLM_PROVIDER=openai LLM_BASE_URL=https://api.openai.com/v1 LLM_API_KEY=sk-your-api-key LLM_CHOICE=gpt-4.1-mini # 嵌入模型（维度决定 schema 中的向量长度） EMBEDDING_PROVIDER=openai EMBEDDING_MODEL=text-embedding-3-small # 摄取阶段专用快速模型 INGESTION_LLM_CHOICE=gpt-4.1-nano # 服务端口 APP_PORT=8058

两点适用前提需要注意：

1. 向量维度必须与嵌入模型一致：sql/schema.sql 中第 31、67、100 行附近的vector维度要按所选嵌入模型修改——OpenAItext-embedding-3-small为 1536 维，Ollamanomic-embed-text为 768 维；且该脚本执行前会先删除既有表。GraphitiClient 侧也通过VECTOR_DIMENSION环境变量（默认 1536）读取同一维度；
2. 必须先摄取后查询：Agent 在空库上无意义，需先跑python -m ingestion.ingest（可把big_tech_docs复制到documents/作为完整示例语料）。

服务启动与查询：

# 终端 1：启动 FastAPI 服务（默认 http://localhost:8058） python -m agent.api # 终端 2：交互式 CLI，可实时看到 Agent 每次调用了哪些工具 python cli.py

API 也提供非流式与流式两种聊天端点（POST /chat、POST /chat/stream），交互式文档在http://localhost:8058/docs。针对本文主题，可直接提问"How is Microsoft connected to OpenAI?"或"Show me the timeline of Microsoft-OpenAI investment"，从 CLI 的 Tools Used 面板可验证 Agent 实际走了hybrid_search/graph_search/get_entity_relationships中的哪些路径。

八、小结

这份 doc5 文档的价值有两层：作为竞争情报文本，它完整记录了微软在 130 亿美元合作存续期将 OpenAI 列入 10-K 竞争对手的事实框架——四大竞争领域、10 亿到 130 美元的注资轨迹、日落条款、搜索/企业/集成三重张力、云多元化动作，以及双侧财务依赖数据；作为工程样本，它是 agentic-rag-knowledge-graph 语料库中"双实体关系 + 时间线"特征最典型的文档，其公司/人物实体恰好落在 graph_builder.py 的预置词表内，而 2019-2024 的注资序列则能映射为 Graphiti 中可时序查询的事实链。对开发者而言，它演示了一个可复制的模式：把结构化的行业关系文档喂入"向量库 + 时序图谱 + Agent 工具选择"的管道，即可把"两家公司是什么关系、关系如何演变"这类问题变成可检索、可溯源、带引用出处的自然语言查询。

【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents