關于調用第三方大模型服務商接口的感受 原創
?“ 軟件開發的原則之一——每引入一個模塊風險就增大兩分”
大家都知道作者現在做的是基于大模型的上層應用開發，之前主要做的工作流和自己部署大模型；雖然操作起來很復雜也很困難，但從功能開發的角度來說定制化比較強，開發也比較簡單。
之前在搞工作流的時候感覺好復雜，主要時間都花在了運維上面，真正的功能開發時間并不長。
這次有個功能需要用到第三方接口，本來以為不需要自己維護大模型能夠減輕很多壓力，只需要關注于功能開發，應該會比較簡單，但等到真正去做的時候才發現想多了。
調用第三方模型服務
之前自己部署模型的時候，一周需要花三天時間搞運維，一天時間搞開發，一天時間搞測試；現在調用第三方模型服務，本來以為會輕松一點，結果是花四天時間開發，一天時間測試，把之前運維的時間全都用在開發上了。
本以為自己脫離了苦海，結果卻發現自己又進入了另一個苦海。
為什么調用第三方服務會這么困難？
當然調用三方服務比較困難并不只是大模型開發中所面臨的，所有需要調用第三方接口的應用都挺困難的，需要面對各種各樣的問題。
比如，第一點文檔不全；很多三方接口的文檔寫的那叫一個亂七八糟，甚至有些根本沒有文檔，只有一些簡單的代碼示例；而作為調用者來說，我們首先要測試接口通不通，而這只是最基礎的一步。
在接口通了的前提下，我們需要去測試接口不同的響應狀態，比如正常響應有哪些；不正常的響應有哪些，有哪些需要注意的錯誤碼，然后不同的錯誤碼響應數據格式是否一致等等。
然后根據不同的響應數據，還需要與自己的業務邏輯做兼容，不同的響應可能會對業務邏輯產生什么影響。
其次，由于大模型的功能問題，導致其響應一般會比較慢，因此大部分都是采用異步或回調的方式，也就是說別人一個接口就可以搞定一個功能；而調用大模型功能至少需要兩個甚至兩個以上的接口才有可能完成一個功能。
這就在無形中增加了很多工作量，而這些接口又直接或間接影響到業務邏輯；這就導致開發難度增大，各種意外情況也會增多。
那為什么自己部署模型就不會有這些問題呢？
事實上自己部署模型也會有這些問題，只要涉及到多個功能模塊之間的調用都會面臨這些問題；但不同的一點是，如果全都是自己的系統，那么自己就可以想辦法保證其中某些功能的穩定性，這樣在處理一些業務邏輯時就不需要考慮一些異常問題和極端情況。
但由于調用的是第三方接口，而我們無法保證第三方接口的穩定性，因此我們就必須去兼容在第三方接口不穩定的情況下所產生的一些極端問題。
而且更重要的一點就是，自己維護的系統可以用更加合適的架構和方式去處理可能出現的異常情況，而使用第三方接口只能是我們去兼容別人，而不能讓別人兼容我們。
這就直接導致需要大量與業務無關的代碼來兼容這些問題。
其次還有一個問題是什么？
如果是自己的接口，接口有哪些響應你一清二楚，你就知道該怎么處理；而調用第三方接口，即使別人給了你文檔，為了安全性，你還是需要把每種可能都測試一遍；而這就需要浪費大量的時間和精力。
還有一點就是，別人的接口是按照別人的業務邏輯和思路進行處理的；雖然別人給了你接口文檔，并且都有說明，但某些參數的作用你可能并不是很了解，但是它可能很重要。
這時就會讓你間接給你的代碼埋下隱患，可能在某些情況下就會出現一些意想不到的意外情況。
總之，自己部署模型自己維護，運維壓力比較大，開發壓力比較小；而使用第三方模型服務，沒有運維壓力，但開發壓力比較大。
因為一個完全自主可控，一個完全不可控。
?
本文轉載自公眾號AI探索時代 作者：DFires
