本文從技術角度出發，以 c3.ai 在官網發布的白皮書作為資料來源，期望能以淺顯易懂的方式向讀者介紹 c3.ai 該公司主要產品 C3 AI Suite 的特色。
本段將會簡單介紹 AI 和應用 AI 的場景，如果讀者已對 AI 有基本了解，可以跳過不看
自 AlphaGo 擊敗李世石以降，AI 走入了普羅大眾的視線，不明原理的人到處散播「AI 將會毀滅世界」的理論；熟稔理論的人則用各種術語打造外人不得其門而入的壁壘。到底，大家在討論的 AI 是什麼？
現在主流的 AI，是使用機器學習與深度學習的方式，以資料作為輸入，基於統計學的框架，結合機率、神經網路等學問，來預測並輸出答案。
舉個大學生課堂作業作為例子，芒果根據外表和色澤可以分成良、優、特級，現在有幾張不知道等級的芒果照片，要怎麼用 AI 來幫助挑選芒果呢？
首先，我們需要大量已經標記好等級的芒果照片，讓機器知道特級、良級、優級的芒果分別有哪些照片，機器就可以根據這些照片的特徵「學習」到如何辨別不同等級的芒果，於是遇到不知道等級的芒果照時，就可以根據過去學習到的模型，比對並告訴我們它比較接近哪一個等級的特徵，並且準確度正比於資料的品質和數量。
但這樣的 AI 實際上是不可解釋的，我們也許可以知道它是根據哪幾個特徵將這顆芒果分類成特級，但這幾個「特徵」對人類是沒有意義的，沒辦法轉換成「因為這顆芒果上斑點面積占 45%，所以分類成良級」，因為機器只是依照你餵給它的資料來判斷這顆芒果和之前的哪一群芒果比較像而已。
再例如與李世石對戰的 AlphaGo 版本，便是在學習超大量的人類棋譜後，並與自己對弈改善結果（畢竟人類的棋譜會有偏誤，往往下某一子會贏只是因為對方實力較弱）。
如果沒有資料呢？新版本的 AlphaGo Zero，不靠任何人類棋譜，自己與自己對弈，在 Google 龐大運算資源支持下，僅僅花了三天棋力就超越原本的 AlphaGo。但即使這樣的 AI 不是參考人類棋譜，也仍然是藉由自己對弈產生大量的對局作為進步的基礎。
我們已經知道現代的 AI 非常仰賴資料的數量與品質，那麼 AI 可以應用在哪些場景幫助企業獲利呢？以下試舉幾個例子。
-
抖音的推薦系統
筆者尚未在字節跳動（抖音母公司）上班，以下論述僅為推測，並不代表真實情況
當使用者 A 滑一部短影片時，APP 會記錄 A 在這部影片看了多少時間、有沒有按愛心、看的時間是早上還是晚上等等的資訊，同時 A 的個人資訊包含性別、年齡、日平均活躍時間等等，透過 A 與這部影片的互動資訊判斷 A 喜不喜歡這部影片，更新 A 的推薦模型；另外，透過相似程度的比較，我們可以用其他跟 A 比較相似的使用者們來回推 A 可能也會喜歡他們喜歡的短影片。
-
Siri
透過輸入大量文字和對話的紀錄訓練之後，Siri 可以分析使用者的語意，選擇適當的行為來回應使用者；同時從使用者的回饋（對 Siri 的行為是否滿意）可以進一步持續的改善 Siri 的模型。
資料可說是 AI 時代的石油，跟資料有關的議題就顯得格外重要，例如資料如何串接讓 AI 應用程式得以訓練模型，這樣一個看似簡單的環節便已讓工程師們足夠頭疼。
現在的軟體圈面臨到一個尷尬的處境是，市場上充斥著各種試圖解決特定問題的服務，例如 Cassandra 是一個適用於大數據的鍵值（Key-Value）資料庫，新增資料的速度快，但修改、掃描資料的效率則不盡人意，而且 Cassandra 只保證最終一致性（Eventual consistency），換句話說，如果 Cassandra 存放的是影片點閱率，則我們並不能馬上得到當下時間點的正確點閱數（像是 Youtube 影片的點閱率就不會即時更新）；點閱率還好，但如果我們存放在 Cassandra 的資料是用戶的錢包餘額，沒有辦法立即知道用戶現在手上的錢有多少就是一件很嚴重的事情了。
上述 Cassandra 有一好沒兩好的特性並不是特例，在現實世界中，我們已知沒有任何一套完美的資料庫可以解決所有需求。在資料庫的領域，有所謂的 CAP 定理，告訴我們一致性、可用性、分區容錯性三者不能兼得；再例如選擇 SQL 還是 NoSQL 存放資料也必須看資料結構容不容易被改變、是不是需要應付超大量的流量等等。因此，企業在搭建基礎建設（Infrastructure）時，往往會使用多種資料庫搭配以應付不同的需求。
不僅僅只有資料庫的類型五花八門，現在是雲的時代，企業大部分的機器和服務都是從各大雲端供應商（Amazon/AWS、Microsoft/Azure、Google/GCP、IBM Cloud...）租來的，以 AWS 為例，提供了 Amazon Aurora 作為 SQL 的方案之一；也提供 DynamoDB 作為 NoSQL 的鍵值（Key-Value）資料庫；同時資料來源也不一定僅限於資料庫，有可能來自 AWS Lambda（無伺服器運算）、AWS IoT（物聯網的服務）等等。
更進一步來說，企業有可能出於風險管理的角度而進行多雲部署，也就是將機器分散在不同的雲端供應商，例如一半的機器使用 AWS，另一半則使用 GCP 等等；也有可能一部分的機器是使用公司內部搭建的，這樣混合雲的策略已經逐漸主流化。
綜上所述，不論是軟體，或者是雲服務的層級，我們都已經走向了前所未有的分眾化和複雜化，參見下圖。
這些軟體和服務用不同的程式語言寫成，且輸出的資料格式並不相容，它們就像一座座孤島，只能靠工程師用程式碼來黏合這些服務，並串成一條流水線（Pipeline，或譯成管線）。某些企業會試圖自己搭建一個 AI 平台（如下圖），然而，這樣做會有以下幾個問題：
-
複雜性
前面提到，由於複雜的基礎設施，資料四散在不同的來源，要訓練一個模型（例如使用者的推薦影片）常需要串接兩位數以上的服務，工程師要深入的了解這些服務，測試、驗證和確認其可靠性，以確保整個流水線可以工作，能處理這種程度的複雜性的工程師並不多，並且以這方式要建立一個統一、通用的資料模型會需要數百人年（person-years）。
-
脆弱
這些串聯不同服務的程式碼，通常為了追求開發效率並不會切分得太乾淨，很容易就形成所謂的麵條式代碼（Spaghetti-Code），這時候如果其中一個資料來源發生問題，常常就會造成整個系統故障，並且難以修復（想像好幾條耳機的線纏繞在一起，而你試圖移除其中一條耳機有多麻煩）
-
難以面向未來
與 AI 有關的技術迭代快速，資料庫的版本也可能常常更新，一旦這些平台上採用的技術或軟體升級時，可能就要改寫程式，讓程式得以繼續正常運作，而這可能需要花好幾個月到好幾年。
上述的問題存在於各大試圖採用 AI 的企業；而 c3.ai 提出了另外一種設計，那就是模型導向的架構（Model-Driven Architecture）。
有別於上圖是以各種服務、軟體為導向；模型導向是以模型為中心，據 c3.ai 的白皮書所說，工程師可以直接操作模型而不需要擔心與特定實體（例如：使用者）相關聯的資料類型、資料的互相聯繫等議題，因為所有與該實體相關的資料、API、連接等都會被抽象（包含）在整個模型裡面。
抽象在電腦科學裡是指，縮減不必要的資訊，以集中設計重要的功能，例如對掃地機器人而言它只要辨別物品是否是障礙物，而不需要分辨這個物品是一隻狗或是一面牆，這時候「障礙物」就是對「一隻狗」和「一面牆」所做的抽象。
因此，這一套 C3 AI Suite 在工程師和大量的服務之間打造了一層抽象層，讓工程師只需要專注於和模型互動，可以將複雜度從原本的$10^{13}$降到$10^3$。
至於什麼是模型呢？C3 AI Suite 給出的答案是：萬物皆可為模型，包含應用程式本身、資料庫、自然語言處理的引擎、圖像識別系統等等。而模型也支援繼承的概念，一個 AI 應用程式可能包含一個關聯式資料庫（SQL），而這個關聯式資料庫會連結到另外一個真正的 SQL 實體（例如 MySQL、PostgreSQL等等）。
使用模型導向架構的一個強大好處是，當有新的解決方案（例如資料庫版本更新）出現時，只要簡單的對該模型擴展即可；如果本來資料庫採用 MySQL，想要換成 PostgreSQL，也只要改變原本的 SQL 模型的連結，讓它從 MySQL 指向 PostgreSQL 就好，這讓企業得以在軟體變動時能立即輕鬆的繼續利用 AI 模型。
這樣的架構，當然也相容於雲端計算的環境，不同的雲端服務是一個個不同的模型，讓混合雲環境的 AI 應用程式也能快速的用模型導向的架構來開發。
以上，就是白皮書的摘要與筆者個人的解析，我們可以看到這份白皮書非常多的著墨在抽象化資料處理的部份，但從官網的展示影片中，我們知道 C3 AI 的野心並不僅僅滿足於此，例如它還提供了一個應用程式商店，讓同事可以互相分享自己寫的程式，也許我今天訓練推薦影片的模型需要使用者的資料，而同事做廣告的精準投放也需要同一份使用者資料，這時候我們如果可以共享這份程式就能提升開發效率。
另外，c3.ai 也推出 AI 的無程式碼平台 c3 ai ex machina，讓不是工程師的商業人才，也能透過圖像化的方式建立 AI 應用程式。
總體而言，C3 AI Suite 整合容易，能因應 AI 與雲端技術不斷更新，將是企業要數位轉型、引入 AI 時值得考慮的商業軟體方案。