# petaV3 双区域房地产 AI Engine 云 GPU 验证与私有化部署计划书

版本：v2.1

日期：2026-08-06

适用对象：PropertyLab / petaV3 管理层、工程团队、mentor、潜在 pilot 客户

代码核对基线：`codex/xiaochengxu`，HEAD `05ee8ae22b18`

计划范围：现有代码核对、云 GPU POC、CN / Global 双区域部署、AI 飞轮、外部客户私有化交付

> v2.1 在 v2.0 的双区域架构上补充阿里云国际站 Phase 0 落地方案、从 POC 首周开始的业务结果标签、500 美元预算硬门、准确的节费停机方式，以及模型镜像和 TLS 安全要求。评审输入来自 2026-08-06 分享材料；云产品事实以阿里云和 vLLM 官方文档为准。

## 1. 执行摘要

PropertyLab 不需要从零训练一个基础大模型。更合理的目标是建立一套可私有部署的 **Real Estate AI Engine**：

1. 复用 petaV3 已有的 AI gateway、业务数据和房地产工作流。
2. 在云 GPU 上验证自托管开源模型，再决定是否采购本地 GPU。
3. 建立中国区域和国际区域两个独立数据面。
4. 让 Worker 分析高频触点，区域 Orchestrator 生成销售判断和 Next Best Action。
5. 记录建议是否被采纳，并与预约、带看、booking、成交和丢单结果连接。
6. 只共享匿名聚合指标、评分方法和版本化方法包，不让原始客户数据跨区域。

老板所说的 “two servers structure” 在生产设计中应理解为两个完整的区域部署，而不是两台单机：

| 区域 | 服务对象 | 区域内保存的内容 | 区域内 AI |
|---|---|---|---|
| CN Data Plane | 中国公司、中国经纪、中国来源客户 | CRM、企微/消息、通话、录音、文件、向量、AI 日志、业务结果 | 中国可用且合规的模型服务 |
| Global Data Plane | 香港以外的国际渠道或按合同落在国际区的客户 | WhatsApp / LINE / Zoom、CRM、文件、向量、AI 日志、业务结果 | 国际模型 API 或 Global 云 GPU |

两个区域使用同一套 petaV3 代码、schema contract、prompt contract 和业务方法，但数据库、对象存储、向量库、密钥、模型端点和运行日志相互独立。

### 1.1 分阶段路线

| 阶段 | 核心目标 | 部署方式 | 主要产出 |
|---|---|---|---|
| Test / Phase 0 | 证明 petaV3 能调用自托管模型，并验证双区域边界 | Global 云 GPU + 两套隔离测试环境 | `internal_ai` provider、1 个 Worker、1 条 Orchestrator 链、评测报告 |
| Phase 1 | 建立内部区域大脑和可测量飞轮 | PropertyLab 云环境，按区域隔离 | RAG、建议事件、采纳率、结果关联、内部 case study |
| Phase 2 | 向外部房地产公司交付私有 AI | 客户私有云、本地 GPU 或区域托管 | CN / Global 交付包、pilot、SLA、商业报价和运维 SOP |

### 1.2 核心决策

- 先租云 GPU，不立即购买本地 GPU。
- 先接入现有 `AiClient`，不建立第二套业务 AI SDK。
- 先做 RAG、工作流和评测，不从零预训练。
- 先做 draft / recommendation，由人确认；自动发送必须逐场景放行。
- 先将原始数据留在所属区域，再讨论任何跨区域聚合。
- Phase 2 首批客户优先采用独立部署，不把现有 `group_id` 当作法律意义上的 tenant 隔离。
- Phase 0 选用阿里云国际站，吉隆坡 `ap-southeast-3` 优先，新加坡 `ap-southeast-1` 仅作库存或能力备选。
- 阿里云吉隆坡仍属于 Global Data Plane；它不能承载被定义为中国大陆区的真实客户数据。
- Phase 0 的核心资产是“输入 + AI 建议 + 人工操作 + 业务结果”的可审计标签链，不是 GPU 本身。

## 2. 本次代码核对结论

### 2.1 petaV3 已经实现的 AI 底座

| 能力 | 当前实现 | 代码依据 | 结论 |
|---|---|---|---|
| 统一 AI 调用 | `AiClient::prompt/chat/stream` | `src/Ai/Services/AiClient.php` | 可以作为所有文本 AI 的 gateway |
| Provider 适配 | Anthropic、OpenAI、Gemini、DeepSeek；Seedance / Deepgram 作为非聊天能力 | `src/Ai/AiCredential.php`、`config/ai.php` | 已有 provider catalog，但没有 `internal_ai` |
| OpenAI-compatible transport | OpenAI 和 DeepSeek 共享 `OpenAiTransport` | `src/Ai/Transports/OpenAiTransport.php` | vLLM 可复用该 transport |
| Prompt registry | 注册 prompt key、管理端覆盖、版本、provider/model pin | `config/ai_prompts.php`、`src/Ai/AiPrompt.php` | 已比 v1.0 假设更成熟 |
| 调用审计 | PROCESSING / SUCCESS / FAILED、输入、输出、token、cost、duration、lead、subject | `ai_requests`、`AiRequestRepository` | 可作为技术监控底座 |
| AI 队列韧性 | 独立 queue、rate limit、circuit breaker、retry、no-overlap | `app/Jobs/Ai/AiJob.php` | 适合接入内部模型 |
| 转录审计 | Gemini / Deepgram 转录也写入 `ai_requests` | `LoggingTranscriber.php` | 语音链路已有统一可观察性 |
| 对话分析 | Call / F2F / Zoom 共用标准化 analyzer | `src/Conversation/ConversationAnalyzer.php` | 是首个 Worker 的最佳入口 |
| AI 管理 UI | provider key、prompt、request log 可管理和查看 | Manage Integrations controllers / Vue pages | 内部模型可接入现有管理面 |

### 2.2 当前已经使用 AI 的业务

| 业务能力 | 当前调用方式 | Phase 0 处理 |
|---|---|---|
| Call / F2F / Zoom conversation analysis | `ConversationAnalyzer` → `AiClient` | 第一优先级 Worker |
| WhatsApp AI draft / auto reply | `GenerateAiReply` → `AiClient` | 只开放 draft POC |
| Portal AI Conversations | streaming `AiClient` | 用于 chat/stream 验证 |
| AI Debate | `DebateRunner` 多 provider | 保留外部模型，暂不迁移全部角色 |
| Amenity demand | queued `AnalyzeAmenityDemand` | 第二批业务试点 |
| Catalogue AI content | queued `GenerateCatalogueContent` | 可用于公开楼盘内容试点 |
| Lead intelligence | `LeadIntelService` | 需先处理隐私和区域限制 |
| Floor-plan / owner outreach | `OwnerListingController` | 可测试生成质量 |
| Transcription | 独立 TranscriptionService + shared log | POC 暂不强制本地化 |
| Video / image generation | 独立 provider helper / pipeline | 不属于首轮本地模型范围 |

### 2.3 数据底座已经具备的部分

- `countries`、`projects.country_id`、`catalog_projects.country_id` 和 `property_analyses.country_id` 已支持市场国家维度。
- catalogue ingestion adapter 明确要求 `providerCode()` 和 `countryIso2()`。
- `catalog_project_sources` 保存 provider-specific 来源记录和 raw payload，canonical catalogue 保持 source-agnostic。
- 香港 reference adapters 已能从 petaV2 reference connection 读取 HK 数据。
- `engagements` 已保存每个 lead × project 的销售生命周期，包括 won / lost、`lost_stage` 和时间。
- `bookings` 已保存 booking、SPA、leader review、取消原因和金额。
- WhatsApp message 已保存方向、发送、送达、已读、失败状态；AI 自动回复会标记 generated、trigger、provider 和 model。
- 小程序侧已有受控的 AI conversation 状态和 inquiry 持久化：候选楼盘由应用层约束，AI 不直接拥有数据库工具；AI 不可用时，咨询提交仍有确定性摘要和两阶段写入兜底。

### 2.4 尚未实现的关键能力

| 缺口 | 代码现状 | 业务影响 |
|---|---|---|
| `internal_ai` provider | provider 常量和 catalog 中不存在 | 不能在 UI 和 prompt pin 中选择 vLLM |
| RAG / vector store | 没有 Qdrant、pgvector 或 embedding pipeline | 模型不能检索 petaV3 私有知识 |
| CN / Global 数据区域 | 没有 `data_region`、`deployment_region` 或 residency policy | 不能证明数据不跨区域 |
| 真正 tenant 边界 | 当前主要是 all / group / team / own visibility | 不足以支持共享数据库的外部多租户承诺 |
| Orchestrator | 没有统一 task delegation / verify / synthesize 服务 | 现有功能仍是多个独立 AI use case |
| Advisor / 方法包 | 没有聚合复盘和版本化下发机制 | “全球大脑”仍是概念 |
| 建议采纳事件 | WhatsApp 的 Use 和 Dismiss 都只清空同一个 `ai_draft` | 无法计算 adoption rate |
| AI 建议与结果关联 | `ai_requests` 与 engagement / booking 没有推荐归因关系 | 无法证明 AI 提升成交率 |
| 区域审计字段 | `ai_requests` 没有 tenant / region | 无法按区域出具审计证据 |

## 3. 产品定义

### 3.1 Real Estate AI Engine 的组成

Real Estate AI Engine 不是一个模型名称，而是一套产品能力：

1. **Model Gateway**：统一调用外部模型和自托管模型。
2. **Regional Workers**：抽取消息、通话、会议、portal 和现场触点中的结构化信号。
3. **Regional Orchestrator**：按 lead 汇总事实、验证冲突、更新画像并给出 Next Best Action。
4. **Private RAG**：在权限和区域边界内检索客户、楼盘、流程和知识文档。
5. **Recommendation Sensor**：记录建议展示、采纳、编辑、发送、执行或拒绝。
6. **Outcome Join**：把建议连接到 appointment、engagement、booking、SPA、won/lost。
7. **Method Control Plane**：版本化管理 prompt、评分规则、workflow 和安全策略。
8. **Audit and Evaluation**：记录质量、延迟、成本、错误、采纳率和业务提升率。

### 3.2 非目标

- 不从零预训练基础大模型。
- 不在 Test 阶段本地化所有视频、图片和语音模型。
- 不让中国原始客户数据进入国际模型 API。
- 不将 embedding 视为可自由跨境的匿名数据。
- 不在没有采纳与结果证据前宣传“提升成交率”。
- 不在没有 tenant 重构或独立部署前销售共享数据库多租户方案。

## 4. 目标架构

```text
                         PETA Method Control Plane
                  prompt / workflow / score / policy versions
                    aggregate benchmark / release registry
                         NO raw customer data
                          /              \
              signed method package    signed method package
                       /                    \
          CN Regional Data Plane       Global Regional Data Plane
        -------------------------      ---------------------------
        China channel adapters         WhatsApp / LINE / Zoom / CRM
        Regional API + queue            Regional API + queue
        Operational database            Operational database
        Private object storage          Private object storage
        Regional vector store           Regional vector store
        CN model gateway / GPU           Global model gateway / GPU
        Worker + Orchestrator            Worker + Orchestrator
        Regional AI audit logs          Regional AI audit logs
```

### 4.1 Meta LOOP 在 petaV3 中的映射

| 角色 | petaV3 责任 | 调用频率 | 数据位置 |
|---|---|---|---|
| Worker | 转录、实体抽取、意图、异议、预算、情绪、draft | 高频、可并行 | 必须在所属区域 |
| Orchestrator | 合并 Worker 结果、冲突检查、lead 状态、NBA、升级 | 每个重要事件或定时 | 必须在所属区域 |
| Advisor | 方法论复盘、评分校准、风险检查、版本建议 | 低频、按需/月度 | 只接收获批的聚合数据 |

模型名称不是架构。Worker、Orchestrator 和 Advisor 必须使用稳定接口，底层模型按区域、成本、质量和合规要求替换。

### 4.2 “一个大脑”的正确工程含义

“一个大脑”不等于把所有原始数据汇入一个数据库。它应表示：

- 一套统一的信号 schema。
- 一套统一的评分和工作流 contract。
- 一套版本化 prompt / policy 发布机制。
- 两个区域独立运行相同方法。
- 只通过受控 export 汇总非敏感评测结果。

### 4.3 数据路由规则

路由不能只根据房产国家决定。系统至少要区分：

| 字段 | 含义 | 示例 |
|---|---|---|
| `market_country` | 房产所在市场 | `HK` |
| `deployment_region` | 当前系统实例所在区域 | `CN` |
| `data_region` | 某份业务数据被允许存放的区域 | `CN` |
| `tenant_region` | 客户公司的主要数据区域 | `CN` |
| `source_region` | 数据从哪个区域/provider 进入 | `GLOBAL` |

中国中介销售香港房产时：

- 香港楼盘 catalogue 的 `market_country` 是 `HK`。
- 中国中介、企微客户、对话、录音和 AI 分析的 `data_region` 是 `CN`。
- 获得授权的公开楼盘产品资料可以发布一个只读 projection 到 CN。
- 中国客户原始数据、向量和录音不能因房产位于香港而写入 Global。

## 5. 数据结构更新方向

本节是 proposal 级别的目标 contract；具体 column、迁移顺序和删除项应与 Database Redesign 文档统一。

### 5.1 可复用现有表

| 现有表 | 继续承担的责任 |
|---|---|
| `countries` | 市场国家、货币、locale、timezone |
| `catalog_projects` | 跨来源 canonical 楼盘 |
| `catalog_project_sources` | provider 来源身份、字段、raw payload、scrape 时间 |
| `projects` | 业务使用中的 working project |
| `leads` | 客户/线索入口 |
| `whatsapp_*`、call、F2F、Zoom | 区域内互动事实 |
| `engagements` | lead × project 销售生命周期 |
| `bookings` | booking / SPA / cancellation 结果 |
| `ai_requests` | 模型调用技术审计 |
| `ai_prompts`、`ai_prompt_versions` | prompt 内容和版本 |

### 5.2 建议新增的区域 contract

对于每客户独立部署，`deployment_region` 可由环境配置固定；对于未来共享平台，才需要 tenant 表和 row-level tenant key。

| 对象 | 建议字段/机制 | 用途 |
|---|---|---|
| 部署环境 | `DEPLOYMENT_REGION=CN|GLOBAL` | 防止运行时调用错误区域 endpoint |
| AI request | `deployment_region`、`tenant_ref`（如适用） | 区域审计和成本归属 |
| 数据导出 | export allowlist + batch audit | 证明跨区域只输出获批聚合 |
| catalogue projection | source、license、published region、version | 控制公开产品资料复制 |
| model endpoint | region、provider、model、policy version | 防止 CN 请求路由到 Global provider |

### 5.3 建议新增的飞轮表

#### `ai_recommendations`

- `uuid`
- `ai_request_id`
- `lead_id`
- `engagement_id`
- `conversation_id`
- `recommendation_type`
- `payload`
- `deployment_region`
- `prompt_version`
- `model`
- `generated_at`

#### `ai_recommendation_events`

Append-only event log：

- `recommendation_id`
- `event_type`: generated / shown / accepted / edited / sent / executed / dismissed / expired
- `actor_id`
- `message_id`
- `metadata`
- `occurred_at`

#### `ai_outcome_links`

- `recommendation_id`
- `engagement_id`
- `booking_id`
- `outcome_type`: appointment / booked / spa_signed / won / lost / cancelled
- `outcome_at`
- `attribution_window`
- `metadata`

现有 `engagements` 和 `bookings` 仍是业务结果 source of truth；新表只负责记录 AI 推荐和结果之间的可审计关系。

### 5.4 方法论控制表

Phase 2 再增加：

- `method_packages`
- `method_package_versions`
- `method_package_deployments`
- `regional_export_batches`

方法包可以包含 prompt、JSON schema、评分参数、workflow definition 和兼容模型列表，但不得包含客户原始样本。

### 5.5 区域数据库原则

- CN 和 Global 不建立数据库级 foreign key。
- 不做跨区域实时 Join。
- 不复制 leads、消息、录音、原始文档或 embeddings。
- catalogue 只能通过明确的 publish/export 流程复制。
- 聚合指标必须达到去标识化和最小样本门槛，再进入控制层。
- 每次方法包发布和聚合导出都要留下版本、操作者、hash 和时间。

## 6. Test / Phase 0：云 GPU 与双区域可行性验证

建议周期：4 周。

建议范围：一个 Global 云 GPU、两个隔离测试环境、合成或脱敏数据。

Phase 0 的目标是验证部署、接入、质量、成本和数据边界，不进行从零预训练或蒸馏。只有当真实业务评测证明通用模型无法达到目标，且已经积累足够的高质量标签数据，才进入微调或蒸馏评估。

### 6.1 Week 0：数据准备和基线

执行：

1. 选定 3 个首批任务：conversation analysis、WhatsApp draft、lead Next Best Action。
2. 从真实业务中抽取代表性样本，经授权后脱敏。
3. 为每个样本建立人工 gold answer 和评分 rubric；在任何 prompt 调优前固定 blind evaluation set。
4. 标记数据来源、客户类型、语言、市场国家、允许区域和 consent / retention 状态。
5. 从第一周开始记录可验证结果：appointment booked、viewing completed、booking、SPA signed、won/lost、发生时间、金额、标签来源和证据记录。
6. 无法确认的结果必须记为 `unknown`，不得用模型推断替代事实标签。
7. 建立外部 provider 当前质量、延迟和成本基线。

验收：

- 目标至少 100 个 conversation analysis 样本，其中冻结 20-50 个经双人复核的 blind evaluation 样本；数据不足时以 50 个为 POC 最低起点并记录局限。
- 目标至少 100 个 WhatsApp draft 样本和 50 个 lead/NBA 场景。
- blind evaluation set 的关键字段和已知业务结果标签完整率达到 90%；未知结果单独统计，不进入 uplift 分母。
- 样本不得包含未获授权的身份证、账户、完整电话或录音。

### 6.2 Week 1：部署云 GPU

执行：

1. 使用公司阿里云国际站账号；创建最小权限 RAM 运维用户，不共享主账号。若 bootstrap 临时使用宽权限，服务器创建后立即收窄。
2. 优先检查吉隆坡 `ap-southeast-3` 的实时库存和报价；缺货或规格不可用时才评估新加坡 `ap-southeast-1`，并记录选择原因。
3. 首选 `ecs.gn8is.2xlarge`（1 × NVIDIA L20 48GB、8 vCPU、64 GiB）；若目标区域没有 L20，备选 A10 24GB 级实例并运行 Qwen3-14B AWQ。任何具体规格都必须以创建页当日库存为准。
4. 选择按量付费、VPC、300-500GB ESSD 和磁盘加密。跨云访问时才使用 EIP；可以走 VPN / 私网互联时不开放公共入口。
5. 安全组只允许 petaV3 出站源访问 443；SSH 只允许 bastion / VPN 或工程师固定 IP；8000 对公网和 VPC 其他主机均不开放。
6. 安装 NVIDIA driver、Docker 和 NVIDIA Container Toolkit。
7. 用固定 vLLM tag 和批准的 image digest 启动服务；模型 repository revision、tokenizer revision、量化文件 checksum 同时写入 deployment manifest。
8. L20 先跑 Qwen3-14B BF16；A10 备选跑经过质量验证的 14B AWQ。首轮把 structured extraction 作为主要判定任务。
9. vLLM 仅绑定 localhost，并启用独立 service API key；对 petaV3 暴露的 Gateway 使用有效 CA 证书或私网 mTLS，禁止自签证书配合 `verify=false`。
10. 建立 500 美元 POC 硬预算，在 50%、80%、100% 设置告警；费用估算必须保存当日 calculator / order 页面证据。
11. 用 OOS 定时任务或 ECS API `StopInstance` 的 `StoppedMode=StopCharging` 在非工作时段停机。Linux `shutdown` / `poweroff` 不会触发节省停机模式，不得作为成本控制方案。
12. 记录模型版本、量化方式、GPU、显存、启动参数、EIP / 磁盘持续费用和实际每日成本。

验收：

- `/v1/models` 和 `/v1/chat/completions` 可从授权 petaV3 环境访问。
- endpoint 不对公网匿名开放。
- JSON response、streaming、timeout 和错误状态可重复测试。
- GPU、token throughput、首 token latency 和显存可监控。
- 500 美元预算告警已测试，非工作时段自动进入节省停机模式；同时记录该模式恢复时可能因库存不足而启动失败的风险。
- TLS 验证开启，客户端不包含 `verify=false`，部署清单中没有浮动 `latest` tag。

### 6.3 Week 2：接入 petaV3 `internal_ai`

现有代码允许复用 `OpenAiTransport`，但仍需正式注册 provider：

1. 在 `AiCredential` 增加 `PROVIDER_INTERNAL_AI`。
2. 将其加入 provider catalog 和 chat provider 列表。
3. 在 `config/ai.php` 增加 label、base URL、verify path、chat path、model catalog 和估算成本。
4. base URL 使用环境变量；service token 继续通过 encrypted `ai_credentials` 管理。
5. 为 POC 模型增加 admin-selectable model id。
6. 验证 `AiKeyService` model resolution 和 prompt pin。
7. 验证 `prompt()`、`chat()`、`stream()`、JSON mode 和失败日志。
8. 增加 provider、transport、model validation 和 request-log 测试。

验收：

- Manage AI Providers 可配置内部 endpoint token。
- Manage AI Prompts 可把指定 prompt pin 到 `internal_ai`。
- `ai_requests` 正确记录 provider、model、prompt、token、duration 和 error。
- 现有 OpenAI / Gemini / Anthropic / DeepSeek 行为不回归。

### 6.4 Week 3：Worker + Orchestrator 最小闭环

Worker：

1. 将 `conversation_analysis` prompt pin 到 `internal_ai`。
2. 运行 Call / F2F / Zoom 标准化 schema。
3. 与当前外部 provider 做 blind comparison，重点计算预算、异议、偏好、意图和 next action 的字段级准确率。

Orchestrator：

1. 增加一个注册 prompt key，例如 `regional_orchestrator`.
2. 输入只使用结构化 Worker 输出、lead facts 和当前 engagement。
3. 输出固定 JSON：temperature、buyer profile、lifecycle stage、risks、next action、confidence、evidence。
4. evidence 必须引用本区域内已有事实，不允许模型虚构来源。
5. 将结果保存为 recommendation，而不是只保存在 AI response text。
6. 每条 recommendation 预留 `shown / accepted / edited / sent / dismissed / executed` 事件，并连接 Week 0 定义的结果标签。

验收：

- 同一 lead 可以从 transcript 进入 Worker，再进入 Orchestrator。
- 输出 schema 可验证、可审计、可重放。
- 错误不会触发自动客户消息。

### 6.5 Week 4：双区域边界演练与 Go / No-Go

建立 CN-test 和 Global-test 两套隔离环境：

- 不同数据库。
- 不同对象存储。
- 不同 vector endpoint。
- 不同 AI endpoint allowlist。
- 不同密钥。
- 相同代码版本和 schema。

演练：

1. CN tenant 的 synthetic lead 只能进入 CN-test。
2. Global tenant 的 synthetic lead 只能进入 Global-test。
3. HK catalogue projection 可经批准发布到 CN-test。
4. CN raw lead、message、recording、embedding 不得出现在 Global-test。
5. 只导出聚合评测指标到 method control layer。

Go / No-Go 最低标准：

| 指标 | 建议门槛 |
|---|---|
| 任务 schema 成功率 | ≥ 95% |
| 关键字段人工准确率 | ≥ 85%，且不低于当前基线 |
| P95 非流式响应 | ≤ 15 秒，按任务另定 |
| 失败率 | ≤ 2%，不含故意故障测试 |
| 区域隔离测试 | 100% 通过 |
| 严重数据泄漏 | 0 |
| 单任务成本 | 可解释且有外部 provider 对照 |
| POC 云支出 | 不超过 500 美元硬预算；人工工时单独列示 |
| 结果标签 | blind evaluation set 已知结果完整率 ≥ 90%，未知项单列 |
| WhatsApp draft | 高风险承诺为 0；记录 edit rate，但 edit rate > 50% 不单独触发 No-Go |

Go / No-Go 应按任务拆分：Qwen3-14B 是否适合结构化抽取，与它是否适合中英双语销售语气是两个结论。结构化抽取失败可阻止首轮接入；draft 质量不足时可继续保持 human-review 辅助模式，不能因此否定整个部署可行性。

## 7. Phase 1：PropertyLab 内部区域大脑与飞轮

建议周期：6-10 周。

### 7.1 数据接入

第一批：

- lead profile 和 enrichment。
- WhatsApp 对话。
- Call / F2F / Zoom transcript 和 analysis。
- engagement、appointment 和 booking。
- working project 和已发布 catalogue facts。
- 经批准的内部销售 SOP。

第二批：

- portal 行为。
- campaign 和广告触点。
- 智能工牌/带看现场信号。
- 财富规划和 property analysis。

### 7.2 RAG 管道

1. 定义每类 document 的 owner、region、retention 和 permission。
2. 只从区域内 source database 或 object storage 读取。
3. 清洗、分段并删除不需要进入检索的敏感字段。
4. 在所属区域生成 embedding。
5. 写入区域 vector store。
6. payload 至少保存 region、lead、group/tenant、document type、source id、permission 和 version。
7. 查询时先做权限 filter，再做向量检索。
8. 返回结果必须保留 source citation。
9. 数据删除或权限改变时同步删除/重建向量。
10. 对 prompt injection 文档做隔离、标记和测试。

### 7.3 采纳传感器

以 WhatsApp draft 为第一条完整链路：

1. AI 生成 recommendation。
2. UI 展示时记录 `shown`。
3. Use 记录 `accepted`，不能再与 Dismiss 共用同一个无语义 API。
4. 如果经纪修改文字，记录 `edited` 和差异指标，不保存不必要的敏感副本。
5. 真正发送后记录 `sent` 和 outbound message id。
6. Dismiss 记录 `dismissed`。
7. 超时未处理记录 `expired`。

### 7.4 结果回填

1. 将 appointment、engagement status、booking、SPA、won/lost 作为结果事件。
2. 以 lead × project 的 engagement 为主要业务关联。
3. 定义 attribution window，避免把很久以后的结果强行归因给一次建议。
4. 记录没有采纳建议的对照组。
5. 按语言、市场、团队、任务类型和 model version 分层评测。

### 7.5 Phase 1 输出

- 内部 AI Brain 可用版本。
- 区域 RAG 和删除/权限同步。
- recommendation / adoption / outcome 数据链。
- 技术质量 dashboard。
- adoption、conversion 和 uplift dashboard。
- 至少一个内部 case study。
- 本地 GPU 采购 Go / No-Go 报告。

## 8. Phase 2：外部客户与 CN / Global 正式部署

### 8.1 推荐交付模式

| 模式 | 适用客户 | 推荐度 |
|---|---|---|
| 客户独立区域云部署 | 首批 pilot、担心数据泄漏的房地产公司 | 最高 |
| PropertyLab 区域托管单租户 | 希望托管但要求数据库隔离 | 高 |
| 客户本地 GPU | 有机房、IT 和严格出网限制的客户 | 中 |
| 共享数据库多租户 | 规模化 SaaS | 暂缓，需 tenant redesign |

### 8.2 中国区域正式上线前置条件

1. 确认中国云、网络、域名、备案和合同主体要求。
2. 由合规/法律顾问确认 PIPL、数据出境和录音处理要求。
3. 选择中国区域可用且满足客户政策的模型或 GPU 服务。
4. 完成企微等中国渠道适配器。
5. 建立 CN object storage、vector store、backup、KMS 和 monitoring。
6. 建立对 Global endpoint 的 egress deny / allowlist。
7. 完成 aggregate export 审批和审计。

### 8.3 中国中介销售香港房产 pilot

建议 demo 流程：

1. 在 Global catalogue 中维护 HK canonical project。
2. 将获授权、可销售的 HK catalogue projection 发布到 CN。
3. 中国经纪通过中国端 CRM / 企微触达客户。
4. Worker 在 CN 分析消息、通话和会议。
5. CN Orchestrator 给出楼盘匹配、异议处理和 Next Best Action。
6. 经纪采纳、编辑或拒绝建议。
7. appointment、booking 和 lost reason 留在 CN。
8. 只把达到门槛的匿名聚合结果用于方法论复盘。

### 8.4 外部 pilot 实施步骤

1. Data Processing / Security Discovery。
2. 数据清单和区域分类。
3. 选择 2-3 个高价值 use case。
4. 部署独立环境。
5. 配置 channel adapters 和 SSO / roles。
6. 导入获批知识和 catalogue。
7. shadow mode 测试。
8. human-in-the-loop pilot。
9. adoption / outcome evaluation。
10. 上线评审、SLA 和 support handover。

## 9. 模型与 GPU 策略

### 9.1 模型分层

| 层级 | 任务 | 策略 |
|---|---|---|
| Worker | 抽取、分类、短总结、draft | 小而快、区域内、低成本 |
| Orchestrator | 综合判断、冲突验证、NBA | 中型高质量模型 |
| Advisor | 月度复盘、策略批判 | 低频高质量模型或人工+模型 |

### 9.2 云 GPU 起步

Phase 0 的参考组合是阿里云国际站吉隆坡 `ecs.gn8is.2xlarge` + L20 48GB + Qwen3-14B BF16；若实时库存不支持，则按顺序评估新加坡同规格，以及 A10 24GB + Qwen3-14B AWQ。阿里云官方说明 gn8is 只在部分地域 / 可用区提供，因此本方案不承诺固定地域一定有货。

POC 不追求一次选出“最终模型”。Qwen3-14B 先证明 structured extraction、JSON schema 和成本；销售语气、复杂双语 draft 继续与现有 frontier provider 对照。若内部模型输出需要较多人工改写，但没有高风险承诺且能节省分析时间，可以定义为 Conditional Go。

记录：

- model revision。
- quantization。
- context length。
- max concurrency。
- tokens/second。
- P50 / P95 latency。
- GPU utilization / memory。
- 每任务成本。

### 9.3 何时购买本地硬件

同时满足以下条件再采购：

- Phase 0 和 Phase 1 达标。
- 有稳定日均 token 和并发数据。
- 12-24 个月 TCO 明显优于云。
- 有机房、电力、散热、网络、备份和运维人员。
- 本地部署是客户合同或合规要求，而不是展示性采购。

## 10. 评测体系

### 10.1 离线质量

- JSON/schema validity。
- 人工事实准确率。
- hallucination rate。
- evidence coverage。
- 多语言质量。
- 安全违规率。
- 与当前 provider 的 blind comparison。
- structured extraction 的字段级 precision / recall / F1。
- WhatsApp draft 的 edit distance / edit rate 和高风险承诺数；不把单一主观总分当成唯一门槛。

### 10.2 在线技术指标

- request success / failure。
- queue wait。
- first-token / total latency。
- input / output token。
- cost per task。
- GPU utilization。
- fallback rate。
- region routing violations。

### 10.3 业务飞轮指标

- recommendation shown rate。
- adoption rate。
- edit rate。
- sent / executed rate。
- appointment rate。
- booking / SPA / won rate。
- lost / cancellation reason。
- 采纳组与未采纳组的 uplift。

不能只用静态“答案好不好”证明商业价值。真正的北极星指标是：在可解释的对照下，使用建议是否提高有效业务结果。

## 11. 安全与合规

- 所有 endpoint 使用 private network、TLS、service authentication 和 allowlist。
- API key 继续使用 petaV3 encrypted credential 机制。
- 原始消息、录音、文件、embedding、prompt log 和模型输出都按敏感数据处理。
- `ai_requests.response_raw` 和 request body 需要 retention、redaction 和最小权限。
- 管理员能看到 AI log 不代表所有员工都能看到。
- RAG 必须先授权过滤，再检索。
- 每个区域独立 backup、KMS、incident log 和 restore test。
- 禁止开发人员用真实客户数据测试个人 AI 账号。
- 方法包与 aggregate export 要签名、版本化和审计。
- 法律和合规结论必须由专业顾问确认，本计划不是法律意见。

## 12. 运维设计

### 12.1 服务组件

每个区域至少包括：

- petaV3 application / API。
- web and queue workers。
- operational database。
- Redis / queue。
- private object storage。
- vector store。
- model gateway / vLLM or approved provider。
- monitoring、centralized logs 和 alerting。

### 12.2 故障策略

- internal model 不可用时，CN 不得自动 fallback 到 Global provider。
- Global 是否 fallback 到外部 provider 由 prompt policy 决定。
- interactive chat 可 fail soft。
- queue job 使用现有 retry / breaker。
- recommendation 失败不得阻断 CRM 核心流程。
- 自动客户消息默认关闭，直到单独批准。

### 12.3 发布

1. 同一 commit 构建区域 image。
2. 使用区域独立配置和 secrets。
3. 先部署 shadow / canary。
4. 跑 region boundary tests。
5. 跑 prompt regression suite。
6. 检查 schema / model compatibility。
7. 才放行 production traffic。

## 13. 商业化方案

### 13.1 可售卖内容

- AI readiness assessment。
- 私有 Real Estate AI Engine 部署。
- channel / CRM integration。
- RAG knowledge setup。
- sales conversation intelligence。
- Next Best Action 和 agent copilot。
- AI governance、audit 和 evaluation dashboard。
- managed model / GPU operations。
- quarterly method package update。

### 13.2 收费结构

| 收费项 | 说明 |
|---|---|
| Discovery fee | 数据、合规、use case、基础设施评估 |
| Implementation fee | 部署、集成、迁移、配置和验收 |
| Infrastructure | 客户直接支付或按实际成本转售 |
| Monthly platform/support | 运维、监控、升级、备份、support |
| Usage fee | token、GPU、ASR、storage 或任务量 |
| Method package subscription | 版本化房地产方法论和评测更新 |

不建议在没有可靠 uplift 数据时直接承诺纯效果付费。可以在 pilot 后增加有上限、有明确定义的 performance component。

## 14. 团队与责任

| 角色 | 责任 |
|---|---|
| Product / Business Owner | use case、成功指标、pilot 客户、商业包装 |
| petaV3 Engineer | provider 接入、事件模型、RAG、区域 routing、测试 |
| AI / ML Engineer | model serving、evaluation、prompt/model experiment |
| DevOps / Security | cloud、network、secrets、backup、monitoring、incident |
| Data Owner | 数据授权、quality、retention、gold dataset |
| Legal / Compliance | 中国和国际区域的数据处理审查 |
| Sales / Customer Success | discovery、training、adoption、case study |

## 15. 时间线

| 时间 | 里程碑 |
|---|---|
| Week 0 | 数据清单、gold dataset、当前基线 |
| Week 1 | 阿里云国际站吉隆坡优先的 Global 云 GPU + vLLM |
| Week 2 | `internal_ai` provider |
| Week 3 | Worker + Orchestrator POC |
| Week 4 | 双区域演练 + Go / No-Go |
| Month 2-3 | RAG、adoption、outcome、内部 case study |
| Month 4-6 | CN / Global 外部 pilot |
| Pilot 通过后 | 决定本地 GPU 和规模化产品 |

Phase 0 设置 500 美元云支出硬上限，但这不是月度长期报价。预算应按创建实例当日的阿里云 calculator / order 页面、模型选择、运行时长、磁盘、快照、EIP 和流量重新测算；工程与标注人工成本必须单独报告。

## 16. 主要风险与应对

| 风险 | 应对 |
|---|---|
| 把多国家当成数据区域 | 分离 market country、tenant region 和 data region |
| 误把 `group_id` 当 tenant | 首批客户独立部署；共享 SaaS 前做 tenant redesign |
| 中国数据误调用国际模型 | region policy + egress deny + integration tests |
| RAG 泄漏其他客户内容 | 物理隔离或 tenant filter、permission-first retrieval |
| 只做 copilot，没有飞轮 | Phase 1 强制 recommendation/adoption/outcome |
| AI 建议被误归因 | attribution window + control group + 分层分析 |
| 模型质量不稳定 | gold dataset + prompt/model version + regression |
| GPU 成本失控 | queue、batch、并发限制、自动关机和任务成本 dashboard |
| Linux 关机但仍持续计费 | 只用 OOS 或 ECS API 进入 `StoppedMode=StopCharging`，并验证实例状态与账单 |
| 节省停机后无法重新启动 | 保留时段缓冲、启动前库存检查和新加坡 / 替代规格 runbook |
| 把阿里云马来西亚误当中国区 | 明确 `ap-southeast-3` 属于 Global；中国真实数据另建大陆部署并做合规审批 |
| 自动回复伤害客户关系 | draft first、人工确认、逐场景放行 |
| 过早买硬件 | 通过真实并发和 TCO 决策 |

## 17. 近期行动清单

### 本周

1. 确认 v2.1 架构、两个区域定义，以及吉隆坡仅属于 Global 的边界。
2. 完成 AI Data Readiness Audit。
3. 选择 3 个 POC 任务、gold dataset owner 和业务结果标签 owner。
4. 建立 `internal_ai` provider 技术 ticket。
5. 定义 recommendation / event / outcome schema。
6. 建立阿里云公司账号、RAM 最小权限、500 美元预算与告警。
7. 获取吉隆坡 L20 和备选规格的实时库存 / 报价证据。
8. 确认 CN pilot 的目标渠道是企微、电话、会议中的哪些。

### 两周内

1. 启动云 GPU 和 vLLM。
2. 完成 petaV3 provider 接入和测试。
3. 跑 conversation analysis 基线对比。
4. 建立 CN-test / Global-test 边界测试。
5. 输出第一版成本、延迟、质量报告。

### 一个月内

1. 完成 Worker → Orchestrator POC。
2. 完成双区域数据泄漏测试。
3. 做 Go / No-Go review。
4. 确定 Phase 1 RAG 和飞轮 implementation backlog。
5. 准备中国中介销售香港房产的 demo 脚本。

## 18. 最终结论

petaV3 已经拥有比 v1.0 proposal 假设更成熟的 AI gateway、prompt 管理、审计、队列韧性、多国家 catalogue 和销售结果数据。因此 Phase 0 不需要重新设计 AI 基础调用层，重点应是正式注册 `internal_ai`、部署云 GPU、建立区域边界，并验证一个 Worker 到 Orchestrator 的闭环。

真正的护城河也不是“我们有一个本地模型”，而是：

- 房地产专属数据 contract。
- 区域内的多触点 Worker。
- 可审计的 Next Best Action。
- 建议采纳与业务结果 Join。
- CN / Global 原始数据隔离。
- 可版本化、可下发、可验证的方法论。

## 19. 官方参考资料

- 阿里云地域代码：Malaysia (Kuala Lumpur) `ap-southeast-3`，Singapore `ap-southeast-1`：<https://www.alibabacloud.com/help/en/user-center/developer-reference/common-region-id-reference>
- 阿里云 GPU 实例族，含 gn8is / L20 48GB 规格与地域可用性说明：<https://www.alibabacloud.com/help/en/ecs/user-guide/gpu-accelerated-compute-optimized-and-vgpu-accelerated-instance-families-1>
- 阿里云 ECS 节省停机模式、计费边界和 `StopInstance` 要求：<https://www.alibabacloud.com/help/en/ecs/user-guide/economical-mode>
- vLLM OpenAI-compatible server 与 API key：<https://docs.vllm.ai/en/latest/serving/online_serving/openai_compatible_server/>
- vLLM 官方 Docker 部署说明：<https://docs.vllm.ai/en/latest/deployment/docker/>

云 GPU 只是验证工具；Real Estate AI Engine、数据飞轮和可复制的私有化交付能力才是最终产品。