前言

在AI領(lǐng)域，來快速實(shí)現(xiàn)一個idea：前后端開發(fā)+部署+展現(xiàn)，如果走傳統(tǒng)的前后端分離開發(fā)+服務(wù)器docker部署等方式，會很重且入門成本很高。

所以，行業(yè)內(nèi)誕生出來了 gradio ：基于python的前端+后端+部署一體的開發(fā)框架?；?gradio，可以很迅速的開發(fā)一個應(yīng)用，部署到線上，通過瀏覽器訪問。

多迅速？

# pip install gradio
import gradio as gr
def call_function(text):
    return 'Hello '+text
gr.Interface(fn=call_function, inputs="text", outputs="text").launch()

很多搞AI算法的同學(xué)，工程能力偏弱，但gradio的出現(xiàn)，解決了：科研探索的成果--無法--方便快捷的展現(xiàn) 的痛點(diǎn)。 國內(nèi)外，也出現(xiàn)了一些基于gradio應(yīng)用的平臺性網(wǎng)站，比如：國外的 huggingface，國內(nèi)的 modelscope 等等。

然而，這種用戶生成式 （UGC）的平臺邏輯，最終繞不開一個點(diǎn)：審核。如何有效控制 UGC 的輸入和輸出，防止平臺成為不法、有害信息的集散地，是國內(nèi)做類似平臺必須面對和解決的一個問題。

所以，本文從技術(shù)角度來探討：如何對網(wǎng)站內(nèi)嵌gradio應(yīng)用的輸入輸出做審核？

1 | 方案

目前，在大方向上可以探索的方案有兩個：

• 基于 nginx 流量劫持和轉(zhuǎn)發(fā)
• 基于 gradio sdk 的二次開發(fā)

1.1 | 基于 nginx 流量劫持和轉(zhuǎn)發(fā)

該方案是在流量入口處做一個監(jiān)聽過濾。

基本思路是：根據(jù) gradio 請求 path，做一個路由轉(zhuǎn)發(fā)，將特定的包含輸入輸出的 api 請求劫持然后轉(zhuǎn)發(fā)到審核服務(wù)里，審核服務(wù)會做如下幾件事：

• 對請求的用戶輸入做審核；
• 通過后，將請求轉(zhuǎn)發(fā)給 gradio 應(yīng)用；
• 接收 gradio 應(yīng)用的返回，做審核；
• 審核通過后，返回給前端用戶側(cè)

在1-4任何一步，出現(xiàn)異常，則直接終止請求。

1.2 | 基于 gradio sdk 的二次開發(fā)

gradio 本身是一個開源的框架，允許開發(fā)者進(jìn)行二次開發(fā)。所以可以在 SDK 層面進(jìn)行改造，來滿足對輸入輸出的審核需求。

1.3 | 比較

• 從比較來看，方案一的優(yōu)勢明顯大于方案二；
• 從長遠(yuǎn)來看，對gradio/streamlit框架的改造，是一個必須要經(jīng)歷的過程。

所以，這不是一個 二選一 的抉擇，而是相互補(bǔ)充的上下游方案的融合。 在本篇中，會針對方案一做一個具體的實(shí)操記錄。

2 | 實(shí)施

環(huán)境說明：

• 基于k8s做服務(wù)編排；
• 以deployment+service+ingress方式部署 gradio 應(yīng)用 (gradio-app)
• ingress使用的是nginx-ingress
• 假設(shè)需要劫持的請求路徑是: /run/predict
• 審核服務(wù)（audit-service）和 gradio 應(yīng)用在一個集群，相互間通過 svc 域名訪問

2.1 | 創(chuàng)建ingress，來劫持發(fā)往 /run/predict 的請求

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /api/v1/audit/gradio?id=$1
    nginx.ingress.kubernetes.io/use-regex: "true"
  name: gradio-monitor-ingress
  namespace: here_is_a_namespace
spec:
  ingressClassName: nginx
  rules:
  - host: abc.com
    http:
      paths:
      - backend:
          service:
            name: audit-service
            port:
              number: 80
        path: /(regex_script_to_match_gradio_app_service)/run/predict
        pathType: Prefix

說明:

• 如果 spec.rules[0].http.paths[0].path 通過正則來匹配，則需要在 metadata.annotations 添加 nginx.ingress.kubernetes.io/use-regex: "true"。
• nginx.ingress.kubernetes.io/rewrite-target: /api/v1/audit/gradio?id=$1 表示將來自 abc.com/(regex_script_to_match_gradio_app_service)/run/predict 的請求轉(zhuǎn)發(fā)給 audit-service:80/api/v1/audit/gradio?id=regex_script_to_match_gradio_app_service

2.2 | 審核服務(wù)的接收和處理

偽代碼如下:

@PostMapping("/gradio")
public void predict(HttpServletRequest request, HttpServletResponse response, @RequestBody Map<String, Object> reqMap, @RequestParam("id") String id) throws IOException {
    log.info("get gradio predict request with params={}", reqMap);
    // request audit process
    boolean pass = false;
    pass = doAuditProcess(reqMap)
    if (!pass) {
       response.getWriter().write("audit failed");
       return
    }
    // redirect request to gradio-app
    Object ret = doRedirectRequest(id)
    // response audir process
    pass = doAuditProcess(ret)
    if (!pass) {
       response.getWriter().write("audit failed");
       return
    }
    response.getWriter().write(ret.toString());
}

3 | 效果展示

審核通過場景

審核不通過場景

以上就是對網(wǎng)站內(nèi)嵌gradio應(yīng)用的輸入輸出做審核實(shí)現(xiàn)詳解的詳細(xì)內(nèi)容，更多關(guān)于網(wǎng)站內(nèi)嵌gradio應(yīng)用審核的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論