# Oracle ERP 私有大模型：本地部署与只读取数

> Source: https://netray.co/zh/oracle-erp-private-llm-zh
> Language: zh
> Publisher: Netray (netray.co)

Oracle ERP 用户可以在自己的环境中运行开放权重大模型，通过只读视图、接口或报表层取数，让业务人员用中文提问。对于仍在使用 E-Business Suite 或 JD Edwards 的企业，这是不必升级系统就能获得 AI 能力的路径；Fusion Cloud 用户则需要先确认数据出口的限制。

Oracle 系 ERP 在中国的用户结构比较特别：大量制造、电子和外资企业仍在运行 E-Business Suite（EBS）12.x，也有企业使用 JD Edwards，近年部分企业迁往 Oracle Fusion Cloud ERP。三种产品的数据访问方式差别很大，AI 方案也要分别设计，不能一概而论。

共同的需求是：让计划、采购、财务人员不依赖 IT 就能查数、查原因、查异常，同时数据不离开企业可控范围。私有大模型的做法，就是把模型放在企业内部，用受控的只读通道连接 Oracle，并把每一次取数都展示出来供核对。

## 三类 Oracle 系统，三种接入方式

EBS 的数据在 Oracle 数据库里，业务表大量带有组织字段，例如采购的 PO_HEADERS_ALL、销售的 OE_ORDER_HEADERS_ALL、库存的 MTL_SYSTEM_ITEMS_B、离散制造的 WIP_DISCRETE_JOBS。直接在这些表上做问答，必须处理多组织（ORG_ID）可见性，否则会看到不该看的数据。更稳妥的方式是建立只读视图或使用 Oracle 提供的公开视图，并按组织和责任（Responsibility）限制范围。

JD Edwards 的表名是 F 开头加编号，例如 F4211 销售订单明细、F4311 采购订单明细、F4101 物料主档，字段名也是编码式的，需要字典来翻译。Fusion Cloud ERP 则是 SaaS，数据通过 REST API、BI Publisher 报表或 OTBI 获取，是否能把数据导出到本地模型，取决于合同和数据出口策略，需要先确认。

- EBS：只读视图、公开视图、按 ORG_ID 与责任限制
- JD Edwards：F 表加数据字典，做字段翻译
- Fusion Cloud：REST API、BI Publisher、OTBI，先确认出口策略

## 典型使用场景

采购方面，可以问「过去半年交期延误最多的十家供应商及其主要物料」；财务方面，可以问「应付账款账龄超过 90 天的发票按供应商汇总」；生产方面，可以问「哪些工单因缺料处于等待状态」。系统把问题转成只读查询，返回结果并展示查询语句，业务人员可以复核。

对于 IT 和顾问，私有模型还可以辅助阅读 PL/SQL 包、报表定制和接口程序，生成变更影响清单，这对仍然维护大量定制的 EBS 系统尤其有用。EBS 的老定制往往缺少文档，AI 可以先生成初稿，由人确认后再沉淀成文档。

- 供应商交期与价格查询
- 应付账龄、对账差异分析
- 工单缺料与等待原因
- PL/SQL 与定制报表的阅读和文档初稿

## 部署架构与数据边界

模型使用 Qwen、DeepSeek、Llama 等开放权重模型，通过 vLLM 或 Ollama 部署在企业自有 GPU 服务器或私有云。检索层为企业文档（SOP、合同模板、制度）建立向量索引，并与结构化查询结合。对 Oracle 数据库，建议使用只读账号，配合 Active Data Guard 备库或定时同步的只读副本，避免问答查询占用生产资源。

写回操作默认关闭。若确有需要，例如创建请购单草稿，只生成草稿，由有权限的人在 Oracle 原界面确认。所有问题、查询、使用的数据范围和模型版本都写入审计日志，便于内部审计和信息安全检查。

- 只读账号，限定视图范围
- 备库或只读副本承载查询
- 开放权重模型本地运行
- 写回只生成草稿，人工确认

## 合规注意事项

外资企业常见的要求是总部审核：数据是否传到境外、模型是否会拿数据训练。私有部署的优势在于这两点都可以直接回答：数据留在境内，模型本地运行，不使用企业数据做外部训练。同时要遵守数据安全法和个人信息保护法对数据分类分级、个人信息处理的要求。

对于 Fusion Cloud 用户，如果数据存放在境外区域，把数据拉到境内模型本身就可能涉及跨境传输，应先由法务和信息安全团队评估。我们不提供法律意见，也不声称持有任何资质，只负责让技术架构配合企业自己的合规决策。

## 起步方式

建议从一个部门、一类问题开始，例如采购交期查询。先在测试环境接入只读通道，用 50 到 100 个真实问题评估正确率和耗时，再决定是否上生产。EBS 项目应特别验证多组织场景和责任权限的过滤是否正确。

评估通常包含：数据路径梳理、表和视图清单、术语表建立、模型与硬件选型、安全与审计设计。我们与 Oracle 领域顾问合作交付，不声称与 Oracle 有官方合作关系。

## 坦率的取舍

如果您已经在使用 Fusion Cloud，并且企业接受使用 Oracle 官方内置的 AI 功能，那么先评估官方功能往往更简单，维护也由 Oracle 承担。私有大模型适合以下情况：数据必须留在本地；系统是 EBS 或 JD Edwards，官方新功能无法直接使用；需要把 Oracle 与 MES、文件共享等多个系统放在一起提问。

另外，如果 EBS 即将迁移，AI 项目应优先选择与系统版本解耦的设计，例如通过视图层隔离，避免迁移后全部重做。

## FAQ

### Oracle EBS 不升级也能用大模型吗？

可以。只要能通过只读视图、公开接口或报表层取到数据即可，不需要升级 EBS 版本。关键是处理好多组织和责任权限的过滤。

### Fusion Cloud ERP 的数据能放到本地模型吗？

技术上可以通过 REST API 或报表获取数据，但是否允许、数据存放区域是否涉及跨境，需要先对照合同和企业数据策略确认，再决定方案。

### 会不会影响生产系统性能？

设计上应避免。建议使用只读账号和备库或只读副本，限制查询的并发和超时，并在上线前做压力测试。

### AI 生成的 SQL 如何保证不出错或不越权？

只允许访问预先列出的视图，禁止写入语句，查询会展示给用户核对，并记录日志。上线前需要用问题集和不同角色做测试，正确率不达标就不应开放。

### 我们的 JD Edwards 字段都是编码，AI 能理解吗？

需要先建立数据字典映射，把 F 表字段翻译成业务含义，再让模型使用。这部分是项目的主要工作量之一。

### 和 Oracle 官方 AI 相比，该怎么选？

如果使用 Fusion Cloud 并接受官方云服务，可以先评估官方功能。如果数据必须留在本地、系统是老版本，或需要跨系统提问，私有部署更合适。