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