01、概述

字節(jié)跳動(dòng) Prompt 平臺(tái)旨在為用戶提供全面的 Prompt 開發(fā)、調(diào)優(yōu)、評(píng)測(cè)及應(yīng)用等全生命周期功能。在這些功能中，打字機(jī)效果的流式輸出大模型結(jié)果是一項(xiàng)至關(guān)重要的特性?；?SSE(Server-Sent Events) 實(shí)現(xiàn)雖然可行，但需要額外編寫 HTTP 服務(wù)，這增加了開發(fā)的復(fù)雜性。而輪詢方式雖然簡(jiǎn)單，但用戶體驗(yàn)并不理想，顯得過于笨拙。至于 gRPC，雖然性能出色，但可能引入兼容性問題，使得部署和維護(hù)變得復(fù)雜。因此，我們借助 Kitex 的 Thrift streaming 能力，成功實(shí)現(xiàn)了流式接口的落地，從而為用戶提供了流暢、高效的打字機(jī)效果大模型結(jié)果輸出體驗(yàn)。

02、業(yè)務(wù)背景

隨著 AI 技術(shù)的不斷發(fā)展，人們的生活正在發(fā)生深刻的變化。以字節(jié)旗下的 AI 產(chǎn)品豆包為例，其中的智能體給人們帶來了許多新奇的體驗(yàn)。其中，AI 男友、AI 女友等趣味智能機(jī)器人尤其受歡迎，它們不僅能夠以風(fēng)趣幽默的方式與用戶互動(dòng)，還能展現(xiàn)出溫柔體貼的一面。

這一切都離不開一個(gè)與大模型緊密相連的概念——提示詞（Prompt）。簡(jiǎn)單來說，Prompt 就是向預(yù)訓(xùn)練模型輸入的文本，用以引導(dǎo)模型生成符合特定需求的文本輸出。形象地講，Prompt 就像是為大模型打造一個(gè)專屬的夢(mèng)境，通過它，我們能夠引導(dǎo)大模型在特定場(chǎng)景下給出更貼切、更有針對(duì)性的回答。

以 AI 女友為例，我們會(huì)通過精心設(shè)計(jì)的 Prompt 來告訴大模型，它的角色是一個(gè)溫柔體貼的虛擬女友。同時(shí)，我們還會(huì)設(shè)定一些限制條件，比如要求它以溫柔體貼的方式與用戶交流，并具備傾聽、理解、鼓勵(lì)和建議等技能。此外，我們還會(huì)詳細(xì)描述它的工作流程，比如在問候時(shí)引導(dǎo)用戶說出自己的名字，為用戶起一個(gè)合適的昵稱，然后與用戶進(jìn)行深入的溝通交流，并提供有益的建議。

通過這樣的 Prompt，我們?yōu)榇竽Ｐ蜆?gòu)建了一個(gè)完整的“夢(mèng)境”，讓它明白自己是一個(gè) AI 女友，并清楚自己應(yīng)該如何與用戶互動(dòng)。當(dāng)這個(gè) Prompt 被激活后，我們與大模型進(jìn)行問答時(shí)，它就會(huì)根據(jù)我們的提示給出相應(yīng)的回復(fù)。比如，當(dāng)我們向它問好時(shí)，它會(huì)引導(dǎo)我們說出自己的名字，并為我們?nèi)∫粋€(gè)可愛的昵稱，然后給予我們鼓勵(lì)和寬慰。

從這個(gè)例子中可以看出，Prompt 在特定場(chǎng)景下對(duì)大模型的輸出起著決定性的作用。更進(jìn)一步地說，它還會(huì)影響到大模型在輸出過程中 token 的消耗以及響應(yīng)時(shí)間的快慢。因此，一個(gè)優(yōu)秀的 Prompt 對(duì)于提升模型輸出效果至關(guān)重要。

03、需求場(chǎng)景

字節(jié)跳動(dòng) Flow 團(tuán)隊(duì)正致力于構(gòu)建一個(gè)全面而成熟的平臺(tái)/方法，旨在幫助 Prompt 開發(fā)者設(shè)計(jì)、迭代、評(píng)測(cè)及優(yōu)化其 Prompt，從而增強(qiáng) LLM（大型語言模型）的表現(xiàn)力。在開發(fā)階段，我們計(jì)劃提供結(jié)構(gòu)化生成和引導(dǎo)式生成的方式，以輔助用戶編寫出高效且精準(zhǔn)的 Prompt，并進(jìn)行相應(yīng)的調(diào)試運(yùn)行。

隨著開發(fā)的深入，我們將進(jìn)一步引入 COT(Chain of Thought)、Few shots 等自動(dòng)調(diào)優(yōu)技術(shù)，以及 APO(Auto Prompt Optimization) 方法，幫助 Prompt 提高回答的正確率。同時(shí)，我們還將提供 Prompt 擴(kuò)縮寫的能力，以優(yōu)化大模型在 token 消耗方面的效率。

此外，為了全面評(píng)估 Prompt 的效果，我們將結(jié)合多樣化的數(shù)據(jù)集對(duì) Prompt 進(jìn)行打分，并深入分析其性能瓶頸，以便進(jìn)行針對(duì)性的改進(jìn)。最終，我們將提供一鍵部署的功能，使開發(fā)者能夠輕松地將 Prompt 能力及其背后的大模型集成到他們的應(yīng)用中。

當(dāng)然，這些功能的實(shí)現(xiàn)都離不開對(duì)實(shí)時(shí)流式傳輸技術(shù)的支持。就像你體驗(yàn)過的 GPT、豆包、百度 AI 搜索等 AI 能力一樣，它們?cè)谟脩籼釂柡?，都采用了打字機(jī)形式的回復(fù)方式，讓用戶感受到數(shù)據(jù)在不斷流入屏幕，從而提高了聊天的流暢性和響應(yīng)速度。這種實(shí)時(shí)流式傳輸技術(shù)正是我們 Prompt 平臺(tái)需要提供的最基礎(chǔ)能力。通過將數(shù)據(jù)分成多個(gè)數(shù)據(jù)流進(jìn)行網(wǎng)絡(luò)傳輸，我們可以有效減少網(wǎng)絡(luò)延遲，提高性能，確保用戶在與大型語言模型交互時(shí)獲得更好的體驗(yàn)。

04、解決方案

為了實(shí)現(xiàn)流式輸出功能，我們進(jìn)行了深入的調(diào)研，綜合考慮了多種方案：

• 輪詢
• HTTP SSE
• Kitex gRPC Streaming(protobuf)
• Kitex Thrift Streaming

首先，輪詢方案由于其呆板性，不符合我們的需求，因此被排除在外。其次，雖然基于 HTTP 的 SSE 是一種可行的方案，但考慮到我們對(duì) RPC（遠(yuǎn)程過程調(diào)用）同樣有嚴(yán)格的要求，因此也需要尋找更為合適的方案。另外，我們發(fā)現(xiàn) Protobuf 協(xié)議的流式處理支持并不能完全滿足我們的需求，尤其是在 Thrift 接口方面。最后，我們注意到了 Kitex 對(duì)于 Thrift Streaming 的支持。當(dāng)時(shí)，Kitex Thrift Streaming 正處于開發(fā)階段，我們果斷決定成為其首批用戶，并以此為基礎(chǔ)構(gòu)建整個(gè) Prompt 平臺(tái)的基本框架。

在架構(gòu)設(shè)計(jì)上，我們首先對(duì)標(biāo) LangChain，建立 LLM 工程化服務(wù)。在此基礎(chǔ)上，我們進(jìn)一步構(gòu)建 Prompt 服務(wù)，以提供最基本的 Prompt 管理及應(yīng)用能力。為了與前端進(jìn)行交互，我們通過 API Gateway 提供 HTTP 接口。而在微服務(wù)之間的通信方面，我們采用了 Kitex 框架，以提供流式接口和非流式接口的支持，確保數(shù)據(jù)的高效傳輸和處理。

通過這一解決方案，我們成功實(shí)現(xiàn)了流式輸出功能，為用戶提供了更加流暢、高效的 AI 交互體驗(yàn)。同時(shí)，我們也為未來的擴(kuò)展和優(yōu)化打下了堅(jiān)實(shí)的基礎(chǔ)。

05、實(shí)踐與踩坑

流式調(diào)用的流程

流式調(diào)用的流程起始于用戶發(fā)起提問。這一請(qǐng)求首先被發(fā)送至網(wǎng)關(guān)，網(wǎng)關(guān)隨后與下游的 Prompt RPC 接口建立連接。Prompt RPC 接口進(jìn)一步與 LLM 工程化服務(wù)建立通信，該服務(wù)負(fù)責(zé)持續(xù)與模型交互，并獲取模型的輸出結(jié)果。這些結(jié)果通過流式的方式逐層向上傳遞，直至到達(dá)網(wǎng)關(guān)層，并最終實(shí)現(xiàn)流式上屏展示給用戶。

在此過程中，我們?cè)?Prompt 服務(wù)中編寫了一個(gè)流式接口，用于處理流式調(diào)用。該接口首先通過調(diào)用下游接口建立與下游的連接，然后通過一個(gè) for 循環(huán)不斷地去接收下游吐給我們的這個(gè)流式的包的結(jié)果。一旦接收到數(shù)據(jù)包，我們通過 send 方法將其向上層透?jìng)?，直至遇到錯(cuò)誤或流關(guān)閉為止，循環(huán)隨之結(jié)束。

在實(shí)現(xiàn)過程中，我們體驗(yàn)到了 Kitex Thrift Streaming 的簡(jiǎn)潔性。然而，我們也遇到了一些問題。尤其是在錯(cuò)誤處理方面，我們發(fā)現(xiàn)代碼運(yùn)行時(shí)無法獲取預(yù)期結(jié)果，甚至導(dǎo)致 CPU 負(fù)載過高。

進(jìn)一步分析錯(cuò)誤日志后，我們發(fā)現(xiàn)在單個(gè)請(qǐng)求中存在錯(cuò)誤信息，特別是關(guān)于首包的 QPM（查詢每秒）超限問題。按照我們的代碼邏輯，遇到這類錯(cuò)誤應(yīng)該快速退出 for 循環(huán)，但實(shí)際情況并非如此。于是，我們開始利用 Kitex 提供的排查手段進(jìn)行問題定位。Kitex 提供了 RPCStart 和 RPCEnd 的埋點(diǎn)，以及更細(xì)粒度的包接收和發(fā)送事件埋點(diǎn)。通過對(duì)這些埋點(diǎn)的分析，我們發(fā)現(xiàn) Kitex 將整個(gè)請(qǐng)求識(shí)別為正常響應(yīng)，并且在調(diào)用鏈路上有大量的數(shù)據(jù)包在發(fā)送。進(jìn)一步查看單個(gè)包的打點(diǎn)信息，也顯示被 Kitex 識(shí)別為正常響應(yīng)。

經(jīng)過初步判斷，我們認(rèn)為 Kitex 的流式處理中可能忽略了業(yè)務(wù)錯(cuò)誤，導(dǎo)致錯(cuò)誤未被正確識(shí)別。與 Kitex 團(tuán)隊(duì)溝通后，他們進(jìn)行了相應(yīng)的調(diào)整，例如在代碼中增加了對(duì) biz status error（業(yè)務(wù)狀態(tài)錯(cuò)誤）的識(shí)別。

基于這次錯(cuò)誤處理的經(jīng)驗(yàn)，我們進(jìn)一步分析了流式調(diào)用中可能遇到的其他異常場(chǎng)景，如建聯(lián)階段的權(quán)限報(bào)錯(cuò)、首包階段的 TPM/QPM 超限、中間包階段的流超時(shí)以及內(nèi)容審核錯(cuò)誤等。我們重點(diǎn)關(guān)注了 Kitex Thrift Streaming 在這些場(chǎng)景下的錯(cuò)誤處理表現(xiàn)，如建聯(lián)時(shí)是否能快速返回錯(cuò)誤信息，以及在首包和中間包返回錯(cuò)誤時(shí)是否能迅速停止流等待。經(jīng)過與 Kitex 團(tuán)隊(duì)的共同調(diào)整和測(cè)試，最終這些場(chǎng)景下的錯(cuò)誤處理均符合預(yù)期。

在服務(wù)治理方面

在服務(wù)治理方面，我們特別關(guān)注超時(shí)和限流兩個(gè)關(guān)鍵環(huán)節(jié)。

首先，超時(shí)管理至關(guān)重要。由于我們的模塊與大模型進(jìn)行交互，這種交互可能涉及秒級(jí)甚至分鐘級(jí)的響應(yīng)時(shí)間。因此，在 HTTP 層和 RPC 層，我們都對(duì)流處理設(shè)置了分鐘級(jí)的超時(shí)限制。這樣做可以避免因無法退出 for 循環(huán)而導(dǎo)致的服務(wù)阻塞，確保服務(wù)的穩(wěn)定性和可用性。

在限流方面，雖然 Kitex 支持在創(chuàng)建流時(shí)進(jìn)行限流，但對(duì)于 LLM 場(chǎng)景來說，我們的關(guān)注點(diǎn)不僅在于建立連接時(shí)的 QPM 限流，更在于大模型 token 消耗的限流。大模型的推理過程中會(huì)產(chǎn)生大量的 token 消耗，如果不加以限制，可能會(huì)導(dǎo)致資源耗盡和服務(wù)崩潰。因此，我們利用 Kitex 實(shí)現(xiàn)了建聯(lián)的限流，同時(shí)借助自己的分布式組件來計(jì)算不同模型下的 token 消耗，并據(jù)此實(shí)現(xiàn) token 級(jí)別的限流。這樣做可以有效地控制資源使用，避免服務(wù)過載。

然而，我們也對(duì) Kitex 抱有期待。我們希望未來 Kitex 能夠提供包粒度上的自定義限流能力。這樣，我們可以更靈活地定義限流規(guī)則，更精確地控制資源使用，從而進(jìn)一步提升服務(wù)的穩(wěn)定性和性能。

06、未來的期待

便捷性

首先，在便捷性方面，我們期待微服務(wù)框架能夠支持更多的測(cè)試工具接入，尤其是針對(duì)流式接口的測(cè)試。目前，對(duì)于 Kitex Thrift streaming 接口的測(cè)試還存在一定的局限性，主要依賴于編寫非流式接口進(jìn)行包裝調(diào)用。未來，我們希望能夠通過泛化調(diào)用等方式，使得流式接口能夠更方便地支持各種測(cè)試工具，提高開發(fā)效率。

AI 場(chǎng)景下的能力

隨著 AI 技術(shù)的蓬勃發(fā)展，越來越多的產(chǎn)品開始融入 AI 能力以優(yōu)化用戶體驗(yàn)和功能。在 AI 場(chǎng)景下，我們對(duì)微服務(wù)框架如 Kitex 提出了更高的期待，期望它能更好地支持 AI 組件的集成與編排，以及適配傳統(tǒng)的框架能力。

• 開箱即用的 AI 組件編排能力

在當(dāng)前的開發(fā)實(shí)踐中，當(dāng)需要集成AI能力時(shí)，開發(fā)人員通常需要自行處理復(fù)雜的邏輯，如調(diào)用 prompt、解析大模型輸出、以及將結(jié)果轉(zhuǎn)換為機(jī)器語言等。這不僅增加了開發(fā)難度，也降低了開發(fā)效率。因此，我們期待 Kitex 框架能夠提供開箱即用的 AI 組件編排能力。

具體來說，我們期望框架能夠預(yù)置一系列封裝好的 AI 組件，如 prompt 組件、大模型組件、結(jié)果解析組件以及 RPC調(diào)用組件等。這些組件應(yīng)該具備高度的可配置性和可擴(kuò)展性，以便能夠適應(yīng)不同的業(yè)務(wù)需求。開發(fā)人員只需將業(yè)務(wù)邏輯傳入這些組件，而無需關(guān)心組件內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)，從而能夠更專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)。

• 靈活的 AI 組件編排能力

除了提供預(yù)置的 AI 組件外，我們還期待 Kitex 框架能夠支持靈活的AI組件編排能力。這意味著框架應(yīng)該提供一種表達(dá)式語言或可視化工具，使得開發(fā)人員能夠輕松地按照業(yè)務(wù)需求編排這些 AI 組件。通過這種方式，開發(fā)人員可以定義組件之間的執(zhí)行順序、通信方式以及并行處理策略等，而無需深入了解組件之間的交互細(xì)節(jié)。這將大大提高 AI 應(yīng)用的開發(fā)效率和可維護(hù)性。

• 傳統(tǒng)框架能力在 LLM 鏈路上適配

在 AI 場(chǎng)景下，傳統(tǒng)的框架能力如服務(wù)治理、元數(shù)據(jù)透?jìng)饕约翱捎^測(cè)性等仍然具有重要意義。因此，我們期待 Kitex 框架能夠在這些方面做出適配和優(yōu)化。

首先，在服務(wù)治理方面，由于 AI 應(yīng)用可能涉及長(zhǎng)時(shí)間的推理過程，因此框架需要提供針對(duì)秒級(jí)甚至分鐘級(jí)響應(yīng)時(shí)間的超時(shí)和限流策略。同時(shí)，還需要考慮如何處理與 AI 組件相關(guān)的異常情況。

其次，在元數(shù)據(jù)透?jìng)鞣矫?，我們期望框架能夠支持?AI 組件之間傳遞元數(shù)據(jù)，以便進(jìn)行更精細(xì)化的監(jiān)控和調(diào)試。這將有助于我們更好地理解 AI 應(yīng)用的運(yùn)行狀況，并快速定位問題。

最后，在可觀測(cè)性方面，我們期待 Kitex 框架能夠提供全面的日志、追蹤和指標(biāo)收集功能，以便對(duì) AI 鏈路進(jìn)行全方位的監(jiān)控和分析。這將有助于我們及時(shí)發(fā)現(xiàn)潛在的性能瓶頸和優(yōu)化點(diǎn)，從而提升 AI 應(yīng)用的性能和穩(wěn)定性。

綜上所述，我們對(duì) Kitex 框架在 AI 場(chǎng)景下的未來期待主要集中在開箱即用的 AI 組件編排能力、靈活的 AI 組件編排能力以及傳統(tǒng)框架能力在 LLM 鏈路上的適配等方面。我們相信隨著技術(shù)的不斷進(jìn)步和團(tuán)隊(duì)的深入合作，這些期待將逐漸變?yōu)楝F(xiàn)實(shí)，為 AI 應(yīng)用的開發(fā)帶來更大的便利和效率。

實(shí)際上，我們團(tuán)隊(duì)已經(jīng)與 Kitex 團(tuán)隊(duì)展開了深入的合作，共同探討如何在微服務(wù)框架中更好地支持 AI 場(chǎng)景。我們相信，在不久的將來，我們將能夠推出一個(gè) MVP 版本的解決方案，為業(yè)務(wù)開發(fā)人員提供一個(gè)簡(jiǎn)單、無縫地與 AI 能力結(jié)合的框架。這將是一個(gè)激動(dòng)人心的時(shí)刻，我們期待著這一天的到來。

項(xiàng)目地址

GitHub：https://github.com/cloudwego

官網(wǎng)：www.cloudwego.io