這是一篇翻譯的文章，原文Musings on building a Generative AI product 鏈接是：

https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product

原作者是：Juan Pablo Bottaro and Co-authored by Karthik Ramgopal

這文章侯老師扔群里的，我看了發(fā)現(xiàn)實(shí)在很有價(jià)值。同時(shí)也發(fā)現(xiàn)這類(lèi)文章直接扔給模型翻譯還是讓人看不明白，也好多錯(cuò)誤，就手動(dòng)翻了下。里面有些編程術(shù)語(yǔ)，看不懂可以看我補(bǔ)的注釋?zhuān)P(guān)注AI智能體的同學(xué)，這文章還是建議努力讀完。4月底發(fā)的，差不多就是AI的在頂級(jí)公司落地的最新?tīng)顟B(tài)了。下面上全文。翻的比較隨性，大家盡量看原文。

在過(guò)去的六個(gè)月里，在領(lǐng)英我們的團(tuán)隊(duì)一直致力于開(kāi)發(fā)一種新的 AI 驅(qū)動(dòng)的產(chǎn)品體驗(yàn)。我們想重新構(gòu)想會(huì)員們進(jìn)行求職和瀏覽專(zhuān)業(yè)內(nèi)容的方式。

生成式人工智能的爆發(fā)讓我們停下腳步，思考現(xiàn)在能夠?qū)崿F(xiàn)而一年前還無(wú)法實(shí)現(xiàn)的事情。我們嘗試了許多想法，但都不怎么靈。最終以信息流和招聘啟事切入找到了釋放AI強(qiáng)大力量的方法，它可以幫助用戶(hù)：

● 總結(jié)關(guān)鍵點(diǎn)，例如從帖子中總結(jié)要點(diǎn)或了解各個(gè)公司的最新動(dòng)態(tài)。

● 關(guān)聯(lián)不同信息，例如評(píng)估自己與某個(gè)職位的匹配度。

● 獲取建議，例如改進(jìn)個(gè)人資料或準(zhǔn)備面試。

● 等等……

那么，這活容易么？哪些進(jìn)展順利，哪些不好搞？在生成式人工智能的基礎(chǔ)上構(gòu)建應(yīng)用其實(shí)很麻煩的。我們遇到了一堆難題。我們希望揭開(kāi)這活的的神秘面紗，分享具體哪些部分好搞，哪些部分不好搞，以及接下來(lái)還需要搞定什么。

概覽讓我們通過(guò)一個(gè)真實(shí)場(chǎng)景來(lái)展示這個(gè)系統(tǒng)是如何工作的。

想象一下，你正在瀏覽領(lǐng)英的動(dòng)態(tài)，偶然發(fā)現(xiàn)了一篇關(guān)于產(chǎn)品設(shè)計(jì)中確保殘障人士可訪問(wèn)性（注:就是那種系統(tǒng)里可以把字體放大好多倍的功能）的有趣帖子。在帖子旁邊，你看到了幾個(gè)入門(mén)問(wèn)題，以便你更深入地了解這個(gè)主題。你感到好奇，點(diǎn)擊了“有哪些例子說(shuō)明確保殘障人士可訪問(wèn)性可以推動(dòng)科技公司的商業(yè)價(jià)值？” 這時(shí)候，在幕后發(fā)生了以下事情：

1.選擇合適的智能體：這是一切的原點(diǎn)。我們的系統(tǒng)接收你的問(wèn)題，并決定哪個(gè)AI智能體最適合處理它。在上面這個(gè)例子中，它識(shí)別出你對(duì)科技公司中如何確保殘障人士可訪問(wèn)性感興趣，就會(huì)將你的問(wèn)題導(dǎo)引到負(fù)責(zé)一般知識(shí)性問(wèn)題的AI智能體。

2.收集信息：然后就得做些基礎(chǔ)工作。AI智能體會(huì)調(diào)用內(nèi)部API和Bing，搜索具體的例子和研究案例，這些例子和研究案例突出了設(shè)計(jì)中的確保這種可訪問(wèn)性與科技公司商業(yè)價(jià)值的關(guān)聯(lián)。這些就是產(chǎn)生最終回答的原始素材庫(kù)。

3.編寫(xiě)回答：有了回答所需要的原始信息，智能體就開(kāi)始編寫(xiě)回答了。它將數(shù)據(jù)過(guò)濾并綜合成一個(gè)連貫、信息豐富的答案，為你提供明確回答。為了避免生成太多的文字并使體驗(yàn)更具互動(dòng)性，會(huì)調(diào)用內(nèi)部API來(lái)對(duì)回答進(jìn)行修飾，比如加入文章鏈接或帖子中提到的人物的資料。

作為用戶(hù)你可能會(huì)接著問(wèn)“我如何將自己的職業(yè)轉(zhuǎn)向這個(gè)領(lǐng)域？”，然后我們會(huì)重復(fù)上面這三個(gè)步驟，但這次會(huì)將你路由到職業(yè)和工作的AI智能體。只需點(diǎn)擊幾下，你就可以深入了解任何主題，獲得可操作的見(jiàn)解或找到你下一個(gè)大好機(jī)會(huì)。

這一切在很大程度上得益于大語(yǔ)言模型（LLMs）的出現(xiàn)，我們認(rèn)為進(jìn)一步分享我們?cè)跇?gòu)建這些功能時(shí)面臨的挑戰(zhàn)和幕后故事會(huì)很有趣。

輕松實(shí)現(xiàn)的部分

整體設(shè)計(jì)

圖1：簡(jiǎn)化的用戶(hù)查詢(xún)過(guò)程。KSA代表“知識(shí)共享智能體”，是數(shù)十個(gè)能夠處理用戶(hù)查詢(xún)的智能體之一

大家可能已經(jīng)注意到，我們的流程遵循了檢索增強(qiáng)生成（RAG），這是生成式AI系統(tǒng)中常見(jiàn)的設(shè)計(jì)模式。構(gòu)建這個(gè)流程比我們預(yù)期的要容易得多。在短短幾天內(nèi)，我們就搭建好了基本框架并使其運(yùn)行起來(lái)：

1.路由(Routing)：判斷問(wèn)題是否在處理范圍內(nèi)，是的話將其轉(zhuǎn)發(fā)給哪個(gè)AI智能體。智能體的例子包括：崗位評(píng)估、理解公司、帖子要點(diǎn)提取等各種智能體。

2.檢索(Retrival)：這是一個(gè)逐步確定詳細(xì)信息的步驟（召回率導(dǎo)向的步驟），AI智能體決定調(diào)用哪些服務(wù)以及如何調(diào)用（例如，LinkedIn People Search、Bing API等）。

3.生成(Generation)：這是一個(gè)精準(zhǔn)度導(dǎo)向的步驟，它篩選檢索到的各種數(shù)據(jù)，過(guò)濾它，并產(chǎn)生最終響應(yīng)內(nèi)容。

鑒于“路由”和“檢索”的分類(lèi)性質(zhì)，微調(diào)它們相對(duì)順暢：我們構(gòu)建了開(kāi)發(fā)測(cè)試集，并使用提示詞工程和內(nèi)部模型進(jìn)行優(yōu)化。然而，“生成”則是一個(gè)完全不同的故事。它遵循80/20法則；很快可以達(dá)到80%的準(zhǔn)確度，但剩下的20%卻耗費(fèi)了我們大部分人的所有工作時(shí)間。當(dāng)你的產(chǎn)品期望99%以上的答案都非常出色時(shí)，即使使用最先進(jìn)的模型，每一個(gè)1%的進(jìn)步也仍然需要大量的工作和創(chuàng)造力。

對(duì)我們而言好使的招數(shù)是：

● 固定的三步流程

● 用小模型干路由/檢索，用大模型干生成

● 基于內(nèi)存數(shù)據(jù)庫(kù)的EBR（Embedding-Based Retrieval (EBR) ），直接將響應(yīng)示例注入到我們的提示詞中（窮人版微調(diào)）。（注：EBR是個(gè)技術(shù)名詞，感興趣的自己再查吧。）

● 在路由和檢索過(guò)程中針對(duì)每個(gè)步驟做特定評(píng)估

開(kāi)發(fā)速度

我們希望多個(gè)團(tuán)隊(duì)并行快速推進(jìn)，因此決定將任務(wù)拆分為由不同人員開(kāi)發(fā)的獨(dú)立智能體（即AI智能體）：崗位評(píng)估、理解公司、帖子要點(diǎn)提取等智能體分別由不同團(tuán)隊(duì)負(fù)責(zé)。

這種方法帶來(lái)了顯著的不良影響（compromise）。通過(guò)并行處理任務(wù)，我們?cè)谒俣壬先〉昧藘?yōu)勢(shì)，但這卻以碎片化為代價(jià)。當(dāng)與智能體的交互可能由不同的模型、提示詞或工具管理時(shí)，保持統(tǒng)一的用戶(hù)體驗(yàn)變得極其具有挑戰(zhàn)性。

為了解決這個(gè)問(wèn)題，我們采用了一個(gè)簡(jiǎn)單的組織結(jié)構(gòu)：

● 一個(gè)小型“橫向”工程小組，負(fù)責(zé)處理公共組件并專(zhuān)注于整體體驗(yàn)。這包括：

○ 各種支撐此產(chǎn)品的基礎(chǔ)服務(wù)

○ 評(píng)估/測(cè)試工具

○ 所有垂直領(lǐng)域使用的全局提示詞模板（例如，智能體的全局身份標(biāo)識(shí)、對(duì)話歷史、越獄攻擊的防護(hù)等）

○ iOS/Android/Web客戶(hù)端的共享UX組件（注：一般就是指按鈕、下拉列表這些）

○ 一個(gè)服務(wù)器端驅(qū)動(dòng)的UI框架，用于發(fā)布新的UI更改，而無(wú)需更改或發(fā)布客戶(hù)端代碼。（注：因?yàn)閁I在服務(wù)端，那就需要有個(gè)在服務(wù)端生成UI的框架，很麻煩的一個(gè)東西）

● 多個(gè)“縱向”工程小組，各自對(duì)其智能體擁有自主權(quán)，例如：

○ 個(gè)性化帖子摘要

○ 崗位匹配度評(píng)估

○ 面試技巧

那些東西對(duì)我們有用：

● 分而治之，但限制智能體的數(shù)量

● 建立一個(gè)中心化的，通過(guò)多輪對(duì)話支撐的評(píng)估過(guò)程

● 共享提示詞模板（如“身份”定義）、UX模板、工具及指令

不好搞的部分

評(píng)價(jià)輸出好壞

評(píng)估我們回答的質(zhì)量比預(yù)期的要困難得多。這些挑戰(zhàn)大致來(lái)自三個(gè)方面：制定指南、擴(kuò)展標(biāo)注和自動(dòng)評(píng)估。

制定指南：以崗位評(píng)估為例：點(diǎn)擊“評(píng)估我是否適合這份工作”卻得到“你非常不適合”的結(jié)果其實(shí)沒(méi)啥用。我們希望它既具有事實(shí)性又充滿(mǎn)同理心。有些用戶(hù)可能正在考慮轉(zhuǎn)行到他們目前并不十分適合的領(lǐng)域，并需要幫助了解差距和下一步行動(dòng)。不能確保這些細(xì)節(jié)的一致性就沒(méi)法讓保持標(biāo)注者保持評(píng)分的一致性。

擴(kuò)展標(biāo)注：最初，團(tuán)隊(duì)中的每個(gè)人都參與了討論（產(chǎn)品、工程、設(shè)計(jì)等），但我們知道我們需要一個(gè)更加有原則的方法，擁有一致且多樣化的標(biāo)注者。我們內(nèi)部的語(yǔ)言學(xué)家團(tuán)隊(duì)建立了工具和流程，使我們能夠每天評(píng)估多達(dá)500次對(duì)話，并獲得以下方面的指標(biāo)：整體質(zhì)量分?jǐn)?shù)、幻覺(jué)率、負(fù)責(zé)任的人工智能違規(guī)情況、連貫性、風(fēng)格等。這成為我們了解趨勢(shì)、迭代提示詞并確保我們準(zhǔn)備好上線的主要參考點(diǎn)。

自動(dòng)評(píng)估是終極目標(biāo)，但仍在進(jìn)行中：沒(méi)有它，工程師只能依靠主觀判斷和對(duì)有限示例的測(cè)試，并且需要1天以上的時(shí)間才能獲得反饋。我們正在構(gòu)建基于模型的評(píng)估器來(lái)估算上述指標(biāo)，并允許更快的實(shí)驗(yàn)，我們?cè)诨糜X(jué)檢測(cè)方面取得了一些成功（但這并不容易?。?。

圖2：我們執(zhí)行的評(píng)估步驟。工程師進(jìn)行快速、粗略的評(píng)估以獲得方向性度量和判斷。標(biāo)注者提供更詳細(xì)的反饋，但大約需要1天的時(shí)間。測(cè)試成員是最終的評(píng)判者，并為我們提供規(guī)模性的反饋，但單個(gè)更改的某些度量可能需要3天以上的時(shí)間。

還在死磕的事：端到端自動(dòng)評(píng)估流程，以實(shí)現(xiàn)更快的迭代。

調(diào)用內(nèi)部API

領(lǐng)英擁有大量關(guān)于人、公司、技能、課程等的獨(dú)特?cái)?shù)據(jù)，這些數(shù)據(jù)對(duì)于構(gòu)建具有獨(dú)特和差異化價(jià)值的產(chǎn)品至關(guān)重要。然而，大語(yǔ)言模型（LLMs）并未經(jīng)過(guò)這些信息的訓(xùn)練，因此無(wú)法直接用于推理和生成響應(yīng)。為了解決這個(gè)問(wèn)題，一個(gè)標(biāo)準(zhǔn)的做法是設(shè)置檢索增強(qiáng)生成（RAG）流程，通過(guò)該流程調(diào)用內(nèi)部API，并將它們的響應(yīng)注入到后續(xù)的大語(yǔ)言模型提示詞中，以提供額外的上下文來(lái)支持生成響應(yīng)。

這些獨(dú)特的數(shù)據(jù)中有很多是通過(guò)各種微服務(wù)中的遠(yuǎn)程過(guò)程調(diào)用（RPC）API在內(nèi)部公開(kāi)的。這些API雖然這對(duì)于人類(lèi)通過(guò)編程方式調(diào)用非常方便，但對(duì)于大語(yǔ)言模型來(lái)說(shuō)并不友好。我們通過(guò)把這些API“包裝”成技能來(lái)解決這個(gè)問(wèn)題。每個(gè)技能(Skill)都包含以下組件：

1.人類(lèi)（和大語(yǔ)言模型）友好的描述：說(shuō)明API的功能以及何時(shí)使用它。

2.RPC API調(diào)用配置：包括端點(diǎn)、輸入、輸出schema等。

3.大語(yǔ)言模型友好的輸入和輸出schema：

a. 基本類(lèi)型（如字符串/布爾值/數(shù)字）

b. JSON風(fēng)格的輸入和輸出schema

4.業(yè)務(wù)邏輯：用于在大語(yǔ)言模型友好的schema與實(shí)際RPC schema之間進(jìn)行映射。

（注：schema是個(gè)編程術(shù)語(yǔ)，也許可以翻譯成模式，拿excel表作類(lèi)比，表頭是schema）

這樣的技能使大語(yǔ)言模型能夠執(zhí)行與我們的產(chǎn)品相關(guān)的各種任務(wù)，如查看個(gè)人資料、搜索文章/人員/職位/公司，甚至查詢(xún)內(nèi)部分析系統(tǒng)。同樣的技術(shù)也用于調(diào)用非LinkedIn API，如Bing搜索和新聞。

圖3：使用技能調(diào)用內(nèi)部API

我們編寫(xiě)了提示詞，要求大語(yǔ)言模型（LLM）決定使用哪種技能來(lái)解決特定任務(wù)（通過(guò)規(guī)劃來(lái)完成技能選擇），然后輸出調(diào)用該技能所需的參數(shù)（函數(shù)調(diào)用）。由于調(diào)用參數(shù)必須與輸入schema匹配，我們要求LLM以結(jié)構(gòu)化的方式輸出它們。大多數(shù)LLM都經(jīng)過(guò)YAML和JSON的結(jié)構(gòu)化輸出訓(xùn)練。我們選擇YAML是因?yàn)樗?jiǎn)潔，因此消耗的tokens比JSON少。

我們遇到的一個(gè)挑戰(zhàn)是，雖然大約90%的時(shí)間里，LLM的響應(yīng)包含了正確格式的參數(shù)，但有大約10%的時(shí)間，LLM會(huì)出錯(cuò)（注：經(jīng)常說(shuō)的幻覺(jué)），并且經(jīng)常輸出不符合要求的數(shù)據(jù)，或者更糟糕的是，甚至不是有效的YAML。雖然這些錯(cuò)誤對(duì)人類(lèi)來(lái)說(shuō)微不足道，但會(huì)導(dǎo)致解析它們的代碼出錯(cuò)。由于10%的比例足夠高，我們不能忽視這些微不足道的錯(cuò)誤，因此我們著手解決這個(gè)問(wèn)題。

解決這個(gè)問(wèn)題的標(biāo)準(zhǔn)方法是檢測(cè)到錯(cuò)誤，然后重新發(fā)提示詞給大語(yǔ)言模型，要求它在這些額外指示下糾正錯(cuò)誤。雖然這種方法有效，但它增加了不小的延遲，并且由于額外的LLM調(diào)用而消耗了寶貴的GPU算力。為了繞過(guò)這些限制，我們最終編寫(xiě)了一個(gè)內(nèi)部防御性YAML解析器。

通過(guò)對(duì)各種調(diào)用參數(shù)（payload）的分析，我們確定了LLM常犯的錯(cuò)誤，并編寫(xiě)了代碼來(lái)在解析之前檢測(cè)和適當(dāng)修補(bǔ)這些錯(cuò)誤。我們還修改了提示詞，以便在這些常見(jiàn)錯(cuò)誤周?chē)⑷胩崾驹~，以提高我們修補(bǔ)的準(zhǔn)確性。最終，我們將這些錯(cuò)誤的發(fā)生率降低到了約0.01%。（注：這其實(shí)是用規(guī)則補(bǔ)足模型的不足，降低成本）

還在死磕的事是：構(gòu)建一個(gè)統(tǒng)一的技能注冊(cè)機(jī)制，以便在我們的生成式AI產(chǎn)品中動(dòng)態(tài)發(fā)現(xiàn)和調(diào)用封裝為L(zhǎng)LM友好技能的API/智能體。（注：可以想象是個(gè)技能商店，智能音箱那種能夠動(dòng)態(tài)添加天氣、音樂(lè)技能的機(jī)制）

保持統(tǒng)一的質(zhì)量

團(tuán)隊(duì)在首月內(nèi)實(shí)現(xiàn)了我們目標(biāo)體驗(yàn)的80%，隨后又額外花費(fèi)了四個(gè)月時(shí)間，致力于將我們的全面體驗(yàn)完成度提升至95%以上——我們勤勉地工作，對(duì)各個(gè)方面進(jìn)行精細(xì)化調(diào)整、優(yōu)化和改進(jìn)。然而，我們低估了檢測(cè)和減輕幻覺(jué)現(xiàn)象的挑戰(zhàn)，以及質(zhì)量評(píng)分提升的難度（注：原文是速度應(yīng)該是筆誤）——起初迅速攀升，隨后便迅速達(dá)到瓶頸期。

對(duì)于那些容忍一定錯(cuò)誤率的產(chǎn)品而言，采用生成式AI進(jìn)行構(gòu)建無(wú)疑是一種令人耳目一新的直接方法。但這也帶來(lái)了不切實(shí)際的期望，初期的快速進(jìn)展?fàn)I造了一種“即將達(dá)成”的錯(cuò)覺(jué)，而隨著后續(xù)每1%提升的改進(jìn)速度顯著放緩，這種快速改進(jìn)的錯(cuò)覺(jué)變得令人沮喪。

構(gòu)建該助手感覺(jué)像是偏離了“原則性”的機(jī)器學(xué)習(xí)，而更像是在專(zhuān)家系統(tǒng)中調(diào)整規(guī)則。因此，盡管我們的評(píng)估變得越來(lái)越復(fù)雜，但我們的“訓(xùn)練”卻主要是提示詞工程，這更像是一門(mén)藝術(shù)而非科學(xué)。

還在死磕的事：對(duì)大語(yǔ)言模型（LLMs）進(jìn)行微調(diào)，以使我們的流程更加數(shù)據(jù)驅(qū)動(dòng)。（注：其實(shí)是肯定會(huì)出問(wèn)題，所以修的要快）

容量與延遲

容量和成員感知到的延遲始終是我們最關(guān)心的問(wèn)題。以下是一些維度：

質(zhì)量 vs 延遲：像“思維鏈”（Chain of Thought, CoT）這樣的技術(shù)非常有效地提高了質(zhì)量并減少了幻覺(jué)現(xiàn)象。但它們需要成員從未預(yù)想過(guò)的tokens，因此增加了成員感知到的延遲。

吞吐量 vs 延遲：在運(yùn)行大模型時(shí)，通常情況是“首個(gè)Token響應(yīng)時(shí)間”（TimeToFirstToken, TTFT）和“Token間響應(yīng)時(shí)間”（TimeBetweenTokens, TBT）會(huì)隨著使用率的增加而增加。在TBT的情況下，有時(shí)延遲甚至?xí)尸F(xiàn)線性增長(zhǎng)。如果你愿意犧牲這兩個(gè)方面的度量，獲得每秒Tokens數(shù)（TokensPerSecond, TPS）的兩倍或三倍增加是很容易的，但我們最初必須將它們限制得很緊。（注：否則用戶(hù)會(huì)覺(jué)得慢）

成本：GPU集群并不容易獲得且成本高昂。在初期，我們甚至不得不為產(chǎn)品測(cè)試設(shè)定時(shí)間表，因?yàn)闇y(cè)試會(huì)消耗太多tokens并阻止開(kāi)發(fā)人員工作。

端到端流式傳輸：一個(gè)完整的答案可能需要幾分鐘才能完成，因此我們讓所有請(qǐng)求進(jìn)行流式傳輸以減少感知到的延遲。更重要的是，我們實(shí)際上在流程內(nèi)部實(shí)現(xiàn)了端到端的流式傳輸。例如，大語(yǔ)言模型（LLM）的響應(yīng)會(huì)逐步解析出應(yīng)調(diào)用的API，并在參數(shù)準(zhǔn)備好后立即發(fā)起API調(diào)用，而無(wú)需等待完整的LLM響應(yīng)。最終合成的響應(yīng)也會(huì)通過(guò)我們的實(shí)時(shí)消息傳遞基礎(chǔ)設(shè)施進(jìn)行流式傳輸，并對(duì)信任/負(fù)責(zé)任的AI分類(lèi)等內(nèi)容進(jìn)行增量處理，直至到達(dá)客戶(hù)端。（注：就是通過(guò)流式提升可感知的響應(yīng)速度，非流式會(huì)導(dǎo)致你等半天突然所有結(jié)果出來(lái)了）

異步非阻塞管道：由于LLM調(diào)用可能需要很長(zhǎng)時(shí)間來(lái)處理，我們通過(guò)構(gòu)建一個(gè)完全異步非阻塞的管道來(lái)優(yōu)化服務(wù)吞吐量，該管道不會(huì)因I/O阻塞的線程而浪費(fèi)資源。

這些因素之間有時(shí)會(huì)產(chǎn)生有趣的相互作用。舉個(gè)例子，我們最初只限制了首個(gè)Token響應(yīng)時(shí)間（TimeToFirstToken, TTFT），因?yàn)檫@對(duì)于我們初期產(chǎn)品延遲有直接影響。然而，隨著我們解決幻覺(jué)問(wèn)題，并且思維鏈（Chain of Thought, CoT）在我們的提示詞中變得突出，如果我們忽略了Token間響應(yīng)時(shí)間（TimeBetweenTokens, TBT）會(huì)對(duì)我們?cè)斐筛蟮膫Γ驗(yàn)槿魏巍巴评怼眛oken都會(huì)增加產(chǎn)品的延遲（例如，對(duì)于一個(gè)200個(gè)tokens的推理步驟，即使是10毫秒的TBT增加也意味著額外的2秒延遲）。這會(huì)導(dǎo)致我們公共平臺(tái)上的某些任務(wù)突然發(fā)出超時(shí)警告，我們不得不迅速增加算力以緩解這一問(wèn)題。

還在死磕的事：

1. 將更簡(jiǎn)單的任務(wù)轉(zhuǎn)移到內(nèi)部進(jìn)行，并使用微調(diào)后的自己的模型進(jìn)行處理。（注：潛在意思是專(zhuān)門(mén)化的模型要和通用大模型進(jìn)行搭配）

2. 為大語(yǔ)言模型（LLM）部署構(gòu)建更可預(yù)測(cè)的基礎(chǔ)設(shè)施。（注：不理解，我猜是LLM吞吐量伸縮需要更可控）

3. 減少每個(gè)步驟中浪費(fèi)的tokens。

收獲

我們說(shuō)的夠多了，為什么不讓產(chǎn)品自己說(shuō)話呢？

這還不錯(cuò)！特別是后續(xù)的建議中讓產(chǎn)品可以像維基百科那樣帶你進(jìn)入一個(gè)充滿(mǎn)好奇心的“知識(shí)黑洞”的功能。

隨著我們不斷提高質(zhì)量、開(kāi)發(fā)新功能并優(yōu)化流程以加快速度，我們很快就會(huì)向更多用戶(hù)推出上述功能。

能夠走到這一步，離不開(kāi)一群優(yōu)秀人士的巨大努力，我們將繼續(xù)學(xué)習(xí)并很快分享更多技術(shù)細(xì)節(jié)。敬請(qǐng)期待！

注：這里的產(chǎn)品、工程實(shí)踐其實(shí)和琢磨事之前分享的各種內(nèi)容基本全部吻合，參見(jiàn)，

這個(gè)時(shí)點(diǎn)的AI太混沌了，宣稱(chēng)有賺錢(qián)方法的大概率是騙子，宣稱(chēng)全無(wú)機(jī)會(huì)的又錯(cuò)的太厲害。研究AI就得解剖麻雀，研究案例，回到現(xiàn)場(chǎng)。反之越高大上、越論文就越危險(xiǎn)。問(wèn)題是案例不好找，所以就有了琢磨事AI碰撞局。研究清楚多個(gè)案例，弄明白底層套路，回到自己?jiǎn)栴}差不多是最靠譜的方式了。對(duì)活動(dòng)感興趣的同學(xué)請(qǐng)聯(lián)系cathywangyue。 老李話一三，公眾號(hào)：琢磨事