Sonatus AI 技術人員建構者

00:00 概覽

歡迎收聽《Driving Innovation 》的最新一集，這是一檔專門探討推動汽車產業邁向「軟體定義創新」新時代的前沿解決方案與技術的播客節目。

今天，我們將深入探討，由適當的 SDV 基礎架構所支援的人工智慧，如何協助原廠製造商（OEM）為車主提供無縫且愉悅的用車體驗。

本次對談的嘉賓是史蒂夫·斯托達德（Steve Stoddard），他是「Sonatus」旗下「AI 」技術人員建構工具的產品經理。

史蒂夫將協助我們了解，這項創新的解決方案如何運用強大的AI 技術與即時車輛數據，以簡化車輛擁有與保養流程。

此外，我們也將探討使這些先進應用成為可能的基礎 SDV 技術。

我們開始吧。

01:00 先進車輛技術的複雜性

史蒂夫，歡迎來到《Driving Innovation 》。謝謝你，桑傑。很高興能來到這裡。很高興你能來做客。如今的車輛都搭載了許多科技。

而且它們也變得非常複雜。這種複雜性會給人們帶來哪些挑戰呢？

是的。這真是個好問題。我認為對駕駛者而言，常見的問題之一是對車輛警示燈的誤解——儀表板上顯示的符號常讓許多原廠（OEM）開始製作這些數位版使用手冊來協助理解這些內容，但這卻忽略了這些符號真正的含義，以及面對這些情況時實際該如何應對。 我認為對維修技師而言，數位化浪潮往往導致必須更換整組零件，而且隨著故障代碼（DTC）和訊號代碼的激增，這些代碼究竟代表什麼意思，反而引發更多混淆。至於原廠（OEM），他們經常面臨這樣的困境：無法針對整個車隊掌握實際狀況，也無法洞察哪些問題正在浮現，進而難以有效避免召回。

那麼，我們今天要討論的是 Sonata 的「AI 」技術人員建構器。我想您接下來可能會告訴我，其中許多問題都能透過類似「AI 」的技術人員來解決。因此，請幫我們了解什麼是「AI 」技術人員，同時也請說明這項解決方案中「建構器」部分的具體內容。

沒錯。絕對是這樣。所以我們發現的一點是，許多使用這類工具的不同使用者，對車輛當下的即時狀況缺乏深入的了解。你知道的，如今AI 領域已有許多進展。

我認為，如果你的車輛出現問題，你可以去問 Google 或查詢 ChatGPT，但問題在於，你得到的答案是基於網路上的資訊，以及它們對你車輛狀況的推測。 真正缺失的是車輛連線的部分——也就是資料連線，以及存取底層資訊的能力，這才是解答問題的關鍵。因此，我們發現，要讓這些AI 技術人員發揮作用，所需的底層技術其實仰賴於「軟體定義車輛」（Software Defined Vehicles），包括資料收集能力（例如Sonatus的產品「Collector」AI ），以及在車內採取行動的能力，這些都對推動這項技術的發展，並讓車輛具備這項功能至關重要。

03:09 介紹Sonatus AI 技術人員

在討論一些底層技術之前，您提到了 SDV。顯然，AI 也參與其中。讓我們聚焦於AI 技術人員能為可能與該系統互動的不同類型的使用者提供什麼協助。我指的是車主、維修技師，甚至原廠工程師。沒錯，完全正確。

因此，以上這三個都是非常好的應用案例，也是此類產品的目標使用者。

對於使用者、車輛駕駛者以及車主而言，AI 的技術人員能協助他們了解車輛中那些不易察覺或難以理解的狀況。 試想這樣的狀況：您的引擎出現問題，但「檢查引擎」警示燈卻未亮起。AI 的技術人員能協助釐清實際狀況，並向車主提供建議，說明是否需要將車輛送修。 此外，當他們提供這項服務時，還能預先將相關數據轉交給維修技師，讓技師能更輕鬆地診斷車輛狀況，並在您送修時備妥正確的零件；如此一來，您就不必等到三週後零件終於到貨才來維修，從而避免車輛長期無法使用的狀況。

至於原始設備製造商（OEM），這項技術使他們能夠從車隊層級一直到服務據點，全面蒐集相關數據，藉此掌握正在浮現的問題，並更深入了解車隊的運作狀況，從而為下一代車款進行改進，或避免因問題擴大而可能引發的召回。

我明白，既然原廠授權維修廠會掌握AI 技術人員所蒐集的資料，這對身為車主的我來說，確實會成為前往這些原廠授權維修廠的誘因。像這樣的解決方案，除了對使用者之外，還能為原廠帶來哪些整體好處呢？

沒錯。完全正確。所以你確實一針見血，毫無疑問。擁有這類洞察力，能讓經銷商自營維修廠的服務體驗更加流暢、更加高效。

這樣一來，他們的服務營運就能更有效率。此外，我認為對原廠製造商（OEM）而言，這確實能帶來滿足感——客戶對該流程以及整體擁有體驗感到滿意。因此，這將進一步提升客戶忠誠度，並讓客戶產生這樣的想法：「嘿，我未來會繼續支持這家廠商，因為擁有這輛車的體驗實在太棒了。下次換車時，我還是會向同一家公司購買。」

對。對。

05:31 使用 Builder 建立「AI 」技術人員

剛才我們談到了「AI 」技術人員本身。為了釐清概念，Sonatus 其實並未親自打造「AI 」技術人員。這正是「建造者」角色發揮作用的地方。請幫我們更深入地了解這部分的內容。

沒錯。完全正確。我稍早提到的一點是，許多原始設備製造商（OEM）正在探索這類數位版使用手冊型應用程式或車載虛擬助理。我們在這個領域發現的一點是，必須針對每款車型進行客製化，因為每款車型都有許多特定的領域知識，無論是不同車型之間，還是不同配備等級之間，等等。

因此，為了實現可擴展性，您確實需要一個平台，讓原始設備製造商（OEM）能夠反覆執行這個流程。 而且，理想的情況是，他們無需精通AI ，甚至無需對車輛本身有深入了解，就能組建一支具備掌握這些資訊能力的技術團隊。正因如此，在Sonatus ，我們打造了一個建構平台，讓原廠（OEM）內的各類使用者能根據實際需求——無論是為客戶服務、內部工程師應用，甚至客戶服務層面——來創建不同類型的技術人員角色。

所以說，他們基本上可以培養出這類技術人員，讓他們專精於特定的車型、配備等級，甚至可能細化到車主層級嗎？

沒錯。所以，他們會提供的一項內容就是關於車輛本身的文件。這些文件包括《車主手冊》，或是針對內部人員的相關資料。例如，針對維修技師，則會提供《維修手冊》、《線路圖》等等。

以 OEM 工程師為使用者而言，通常您可能會擁有 FMEA 文件或其他故障樹等資料。這些內容便構成了關於車輛的工程知識。接著，您需要將這些資料與來自車輛的實際即時數據進行配對，而這正是您開始整合各類資訊的起點，例如根據車輛 VIN 編號及特定車主所對應的實際車輛數據，以及維修紀錄、製造歷史等資訊。 所有這些都是可行的。

這確實取決於原始設備製造商（OEM）實際希望連線的各種資料來源。而這又將取決於他們為該技術人員所設計的具體使用情境，以及該系統所針對的特定使用者群體。

所以這簡直就像是擁有專屬的「AI 」技術人員一樣。我超愛這個。

07:36 推動 SDV 技術及AI

那麼，我們現在開始探討這項技術實際上是如何運作的。顯然，其中涉及AI 的技術，但你不能只是把AI 直接套用到車輛上，對吧？顯然需要一些先決條件或必要基礎，才能讓這類應用真正得以部署。請幫我們了解這些基礎技術有哪些。

是的，絕對沒錯。因此，我們認為其中一項關鍵要素，就是能夠從車輛本身獲取數據。也就是說，那些安裝在車輛上、連接到車載網路，並能與不同電子控制單元（ECU）進行通訊的產品，必須能夠存取所有車輛資訊，而不僅限於特定的故障代碼（DTC）或網路的特定區域。

因此，這是一項作為車載軟體基礎技術的核心，用於即時收集該數據，並能讓不同節點之間相互存取。第二個面向則是將這些數據傳回雲端，這更偏向於數據收集產品，例如Sonatus collector，AI ，它透過非常輕量化的政策將數據傳回雲端。 一旦具備這些基礎元件，您便能開始建構更全面的功能，並導入如AI 等特定模型，使其能基於車輛數據進行運算。

也就是說，這需要非常具體或特定領域的專業知識，因此系統不僅依賴「AI 」技術人員本身，還能調用這些不同的代理程式，讓它們存取各類工具，並據此推斷車輛的相關資訊。

09:06 實作代理模型

最近關於「代理模型」（agentic model）的討論相當熱烈，這種模型不僅是分析數據並從中推論，更是一種「閉環」的運作方式。請問在「AI 」的技術建構工具或整體基礎架構中，是否有任何功能適合應用於這種代理模型？

絕對沒錯。所以，我們剛才提到的所有不同資料來源，通常都應該將它們整合成獨立的代理程式。這些代理程式可說是「AI 」專用的模組，在某一項特定任務上表現得非常、非常出色。例如，檢視這份使用手冊的資料，或是建立這些資料庫來解析來自車輛的訊號。

因此，它不僅必須能夠存取資料，還必須能夠解讀這些資料，並明白：「嘿，這些訊號——特別是在這個時間點——代表著這個問題。」 並依據這些資料，結合對設計文件的了解，系統便能判斷：「啊，當我看到這類情況時，就是這類問題，而這正是我需要向使用者提出的建議。」因此，這些不同的代理程式通常會連接到不同的資料來源，藉此，您便能善用這些不同的工具。

其中一項功能，例如，是連接到Sonatus 資料收集器（AI 產品），您可以在此根據AI 技術人員的解讀，部署新的資料收集政策。因此，系統能夠根據用戶查詢分析來自車輛的資料，並實際啟動新的資料政策，將其部署至車輛，進而開始收集原本甚至無法取得的資料。

看來，AI 的技術人員幾乎是在即時思考接下來該採取什麼步驟，以及我還需要哪些額外資訊，才能做出正確的診斷與回應。

10:42AI 涉及的模型

讓我們稍微談談AI 的一些特定技術。

這些是你們傳統的AI 機器學習模型嗎？你們在此使用的是什麼類型的模型？

沒錯，完全正確。一般來說，我們使用大型語言模型（LLMs）的方式，就像如今常見的許多其他應用一樣。歸根結底，這些模型都是基於基礎的大型語言模型，但我們傾向於採用開源模型，並對其進行微調，進而打造出更符合內部需求的專屬模型。其中一個原因在於，這樣做能讓模型在特定的汽車領域中表現得更好。 第二個原因是，許多原始設備製造商（OEM）希望自行託管模型，並確保其資料受到保護——這既涉及從終端使用者角度出發的個人識別資訊（PII）資料，也包含 OEM 可能作為「AI 」技術人員知識來源所提供的專有資料。 因此，我們以這些客製化大型語言模型（LLMs）為基礎，並導入「檢索增強生成」（retrieval-augmented generation）及「代理框架」（agentic framework）等技術；總體而言，我們運用系統提示（system prompting）的專業知識，讓所有元素能無縫協作。

明白了。

11:43 總結與收尾

總而言之，解決方案中除了包含「AI 」這部分，還包含其背後的基礎架構。您提到需要建立更易於存取的網路，以及建立共通的資料交換機制，以便將資料餽入模型中。我推測這正是服務導向架構（SOA）等概念發揮作用之處。這大致上就是整體方程式中「SDV」所對應的部分。

沒錯。車載電子工程（EE）架構確實扮演著重要角色。透過存取所有這些不同的資料來源，不僅能整合一般的遙測資料，還能納入故障代碼（DTC）、日誌檔案等各類資訊，甚至包含網路流量資料——這些資料都可能派上用場，特別是當你考慮到網路安全以及這類應用場景時。 因此，擁有更現代化的架構確實至關重要，因為這能讓這些AI 技術人員具備更強大的能力，這點毋庸置疑。

太棒了。此外，這些內容都詳載於我們剛發布的最新解決方案簡報——《AI 技術人員培訓方案簡報》中。謝謝你，史蒂夫。這場分享非常有啟發性，我們期待能在另一集《driving innovation 》節目中再次邀請你。

太棒了。謝謝你，桑傑。這真的很有趣。Sonatus的「AI 」技術建構器，正是絕佳的範例，展現了 SDV 技術與車輛AI 如何協助原廠製造商（OEM）革新車輛擁有體驗——不僅能消除車輛保養與維修的麻煩與壓力，同時還能建立品牌忠誠度並創造客戶終身價值。

請至sonatus .com 下載《AI 技術人員建構器》解決方案簡報，以獲取更多詳細資訊，並預約示範，親眼見證其實際運作。

感謝您收聽本集《Driving Innovation 》，我們期待在下一集與您再會。