1. 核心思路：将AI算法带到数据所在之处，减少数据移动。
—— 记得pg数据库利用colBERT来进行重排序（文章《多向量 | 提升召回相关性》），而不是让重排序的模型（如BERT，BGE ReRanker，Cohere ReRanker）来做，也是为了减少data moving。在RAG中减少数据移动，在可控可信的范围内，还是比较重要的。
2. 根本优势：控制现代数据栈的总拥有成本（TCO），无需安装多种类型的数据库。原生支持多种数据模型，有效防止了数据碎片化。支持“统一混合向量搜索”（Unified Hybrid Vector Search），允许在单条SQL查询中，将基于语义的向量搜索与传统的结构化、文本、JSON、图和空间数据搜索相结合的检索。
—— 对于别的数据库来说，确实需要每个功能一种数据库。但是对oracle来说，全包。
3. 数据库内嵌AI代理(In-Database AI Agents)，将一个多步骤、涉及数据转换和处理的复杂任务，完全封装在数据库内部，通过一条或一组SQL/PLSQL语句完成，并接受数据库核心引擎的全面治理。如在数据库内处理PDF文档并生成向量嵌入。他与其他数据库调用外部AI模型，核心区别在于，Oracle 26ai的Select AI Agent 框架允许代理的定义、运行和治理都发生在数据库内部 。这使得代理能够以更高的安全性和效率直接访问数据，并继承数据库的事务、安全和高可用性等企业级特性。
—— 原来复杂的工作量，多个组件的引入，多个模型的使用，都可以在一个oracle数据库中，用SQL来实现了。
4. 开放的AI数据湖仓 (Autonomous AI Lakehouse) 通过原生支持开放的在oss对象存储上的Apache Iceberg表格式。
—— 以一个统一的对象存储表格式，打通各个云的对象存储上的表。方便进行数据湖服务。可能，在Costdown云费用统计时，再也不用：CUR -> S3 -> Glue中的data catalog 下的 database -> Athena取这个database的数据，以SQL的方式做报表统计。
（注：CUR，全称cost and usage report，现在改名叫data export，在billing and cost management的菜单下，非常轻量，几乎不算一个服务，算billing 功能的一个feature）
5. 数据注解 (Data Annotations)，不同于数据库的comment，为AI工具、代理和代码生成器提供机器可读的语义上下文、特征和约束。
—— 我们之前探索过让mcp来通过自然语言来给我们统计报表，告诉我们结果，但是如果不能让ai知道表定义，字段的含义，表的关联约束关系，ai不太容易生成每次都对的报表。而让ai“懂得”表含义，要么利用comment，要么在提示词中告诉ai相关定义，现在有了annotation，一切问题迎刃而解了。
6. Oracle 26ai支持广泛的部署选项：包括Oracle自家的OCI，以及通过Oracle Database@Azure, @AWS, @Google Cloud等服务部署在其他主流云平台上，以及如 Exadata 和 Oracle Database Appliance – ODA的本地部署。
—— 之前有同事提到过，他买了Oracle服务器，但是能和azure打通，之前还不太明白，为什么明明买的是oracle cloud上的云服务器，能连微软的网络。现在我开始明白了，可能是Oracle Database@Azure的战略了，oracle的云主机、oracle的数据库部署在azure上。