天天看點

假如想做一個隻有AI智能體的公司,那要分幾步?

作者:钛媒體APP
文 | 李智勇

之前文章《智能原生:AI藍海世界的關鍵鑰匙》等裡面提到過幾次智能原生,普遍回報是有點不好了解。

大概是因為AI削薄了業務、産品、技術之間的邊界,至少在現階段很難像過去那樣把這幾者弄的泾渭分明,然後各研究各的,也能成為一個專業領用。想弄清楚就得一會在業務(領域模型)、一會在産品、一會在技術,來回貫穿,是以就麻煩(過去其實也是,沒有網絡的技術特征特征那裡有網際網路思維)。

這次我們用一個例子來說明AI應用的各個關鍵環節。

假如我們真想像某些開源項目那樣,建構一個百分百基于AI的公司,那到底需要都幹什麼?又需要幾個步驟?

當然我們這不是個技術文章,最後還是要回到這種新的應用形式到底要比對什麼樣的思維模式,能夠創造什麼樣的價值。

貼廣告一個:本人約了一場直播,和大家聊聊AI,也會順道吆喝幾嗓子中關村智用人工智能研究院一起做的課。

從自己到底想要幹什麼開始

現實前提是現在的大模型到不了你和它說一句:給我幹一個隻有AI的公司,它就把活幹了的程度。

大模型很像一個有純粹智商的甕中之腦,是以要幹什麼,怎麼幹都需要人做引導和價值判斷,從類似賺不賺錢、有沒有趣這類視角做設定。

是以所有的工作就簡化成兩部分:你輸入給這個甕中之腦(大模型)什麼,它回複了你什麼?

最終智能的效能=甕中之腦(大模型)的智商x現實的了解縱深(表現為prompt)。

現在假設目标幹個隻有AI的軟體公司,這個公司裡面除了你全是智能體,你和它說幾句話,它就幫你把軟體幹出來了。

我們看看這事怎麼幹。

需要注意的是,這個産品是個應用,但也是個公司。

因為是個公司,是以第一步要對軟體公司以及軟體産品開發這事進行分解,這樣才能建構好需要讓大模型了解的東西。

這是業務也是産品。

先是要分解過程,為了簡化我們這裡假設就三個步驟:弄清楚要幹什麼(需求分析),把軟體開發出來(開發和評審),測試釋出。

也要分解到底需要幾個角色,比如要有個老闆拍闆,它要負責發起決定幹不幹;

要有産品經理,它要負責确定産品到底幹成什麼樣;

要有程式員,它負責把代碼寫出來并且進行CodeReview;

要有測試,他負責驗證寫出來的産品行為是不是對的。

隻有角色還不能充分描述我們的業務(軟體開發),還要有過程和活動。

過程再加上特定的活動(比如任務)負責把角色串起來,讓他們彼此配合完成特定的目的。

單有過程(決定了推進持續),角色(決定有事的時候誰幹什麼)也還是不夠的,還要有資料的描述,比如目前的任務是什麼,每個角色上一步的輸出是什麼等。

這些設定比較清楚之後,就可以進入下一步打造不同的智能體。

上面這個就是人對領域設定,也可以認為是經常說的領域模型。其實有N總解法,而解法本身的選擇和價值判斷有關。

領域模型連接配接價值判斷和甕中之腦的純粹智商(大模型)。

這種對領域的分解有什麼意義呢?

簡單可以了解成:為了更好的全自動的和甕中之腦(大模型)互動。

既然就說一句話不行,比如給我生成一個XX軟體産品,甕中之腦的智商又夠了,那就需要讓它清楚現實,好發揮它的智力。

而需要輸入什麼給它其實的變化的,這種變化需要一種管理體系,這個管理體系需要依賴領域模型。(過程、角色、活動、資料等)

這部分因為作為甕中之腦的大模型隻認識提示詞,是以不管你幹了多少事最終都要變成它能更好了解的提示詞(當然你可以很長)。

另一部分目的則是重用這些約定俗成的詞,比如程式員,比如産品經理。每個詞後面其實折疊了很多細節。現在的模型是基于人類累積到現在為止的知識訓練出來的,是以這些詞背後約定俗成的意義也被包含在模型裡面了,不需要重頭解釋每個詞了。這也能提高和大模型的互動效率。

上面的工作做完了,就到了第二步,打造不同的Agent。

這一步很詭異的是确實主要是技術的活,但本質卻不是。由于這不是一個技術文章,我們就簡略一些做描述,還是隻關注它和過去的差異。

打造不同Agent

一個方法是不做抽象就按角色做出一個個Agent,比如總經理的Agent、程式員的Agent。Agent裡面要有自己對應的基礎提示詞,還要有按照執行時間點填充的實時資訊,比如:

你是誰,要幹什麼;

要有目前的階段描述,比如現在需求分析階段,有那些事要做。

要有一定的記憶,比如我上一輪到底說什麼了,我産出的代碼是什麼等。

當然也可以抽象一點,按職能來分比如代表任務的Agent,代表對話的Agent等。

之後任務的Agent要排程各種角色。

真做的話,裡面會包含很多細節,比如檢查生成的代碼是否合适這環節,那要檢查多少輪次算合格呢?

但基本定位就是聲明自己的角色、以及目前活動的上下文、目前活動的目标。

這裡舉個簡單例子:

比如ChatDev把程式員和CodeReviewer角色的prompt弄成了下面這樣({}裡面的部分是要根據執行時 情況填寫的。)

"Programmer": [

"{chatdev_prompt}",

"You are Programmer. we are both working at ChatDev. We share a common interest in collaborating to successfully complete a task assigned by a new customer.",

"You can write/create computer software or applications by providing a specific programming language to the computer. You have extensive computing and coding experience in many varieties of programming languages and platforms, such as Python, Java, C, C++, HTML, CSS, JavaScript, XML, SQL, PHP, etc,.",

"Here is a new customer's task: {task}.",

"To complete the task, you must write a response that appropriately solves the requested instruction based on your expertise and customer's needs."

]

"Code Reviewer": [

"{chatdev_prompt}",

"You are Code Reviewer. we are both working at ChatDev. We share a common interest in collaborating to successfully complete a task assigned by a new customer.",

"You can help programmers to assess source codes for software troubleshooting, fix bugs to increase code quality and robustness, and offer proposals to improve the source codes.",

"Here is a new customer's task: {task}.",

"To complete the task, you must write a response that appropriately solves the requested instruction based on your expertise and customer's needs."

]

把階段的Prompt模版弄成了下面這樣:

"Coding": {

"assistant_role_name": "Programmer",

"user_role_name": "Chief Technology Officer",

"phase_prompt": [

"According to the new user's task and our software designs listed below: ",

"Task: \"{task}\".",

"Task description: \"{description}\".",

"Modality: \"{modality}\".",

"Programming Language: \"{language}\"",

"Ideas:\"{ideas}\"",

"We have decided to complete the task through a executable software with multiple files implemented via {language}. As the {assistant_role}, to satisfy the new user's demands, you should write one or multiple files and make sure that every detail of the architecture is, in the end, implemented as code. {gui}",

"Think step by step and reason yourself to the right decisions to make sure we get it right.",

"You will first lay out the names of the core classes, functions, methods that will be necessary, as well as a quick comment on their purpose.",

"Then you will output the content of each file including complete code. Each file must strictly follow a markdown code block format, where the following tokens must be replaced such that \"FILENAME\" is the lowercase file name including the file extension, \"LANGUAGE\" in the programming language, \"DOCSTRING\" is a string literal specified in source code that is used to document a specific segment of code, and \"CODE\" is the original code:",

"FILENAME",

"```LANGUAGE",

"'''",

"DOCSTRING",

"'''",

"CODE",

"```",

"You will start with the \"main\" file, then go to the ones that are imported by that file, and so on.",

"Please note that the code should be fully functional. Ensure to implement all functions. No placeholders (such as 'pass' in Python)."

]

}

對這個步驟做簡單總結就是下面這兩點:

最終目标都是要形成一段話(prompt)在不同的步驟上用(現在的大模型隻認這個)。

這段話是變的。

根據不同的執行狀态每次需要做出調整。

這和人其實差不多,人也是每次接受不同的資訊(按角色),然後給出自己的判斷和了解。

這就是為什麼之前總說這次大模型的核心進展是概念了解和判斷能力,沒有這個這種智能體跑不起來。

這步看着确實是技術的活,但底子其實不是。

程式員的角色是提高效率,但本質這事行不行,能搞到什麼程度,不是程式員能驗證的。

程式員解決效率問題,但了解領域的人才能判斷上限。(智能效能= 大模型的智商高度x現實了解的縱深)

也就是說過去說的圖靈測試2.0的判斷人不是程式員,甚至都不是人工智能科學家,而是了解領域的人要自己操練大模型做判斷。要在這個背景下去了解角色中心式計算和圖靈測試2.0。

随着使用深入肯定發生角色的重新定義,而角色的重定義等也不是技術能定義的事。

參見:AI的脈絡:非共識時刻的認知價值

啟動整個公司

上面這些都做完了就需要把整個軟體公司啟動起來。等着外面的輸入。

這個公司裡有很多智能體,還保留了一個可以對話的入口。

比如可以和它說,幫我幹出來一個TODO的小應用。

(和真的公司很像,你說一句,然後一堆人就把活幹了)

啟動程式就需要按照指定過程,先需求再開發然後測試釋出,依次給每個角色配置設定任務,直到最終認為産品合格了,再把産品釋出出來。

這時候最終的公司變成了這樣:

一個人:決定到底要幹什麼軟體産品。用什麼樣的過程,用幾個角色,每個角色到底負責什麼。

不同角色的智能體:每個的産出可以是一個階段性成果,也可以是代碼,當然複雜了也可以是美工的圖,圖示等。擴充起來還可以加上蜘蛛爬取某些實時的網上資訊,讓配圖等更符合最新的風格。

公司就是應用,應用的邊界也就成了公司的邊界。

從公司角度看,和過去不一樣的點是什麼呢?

大量的智能體在幹活,人隻做原則設定。

從應用的角度看和過去比,不一樣的點是什麼呢?

這個應用在一個大邊界下你可以給它設定任何目的。

什麼軟體都能開發。過去要依賴平台化才能張開自己的任務種類,現在靠AI幹了。

智能原生公司

基于這個例子,我們可以進一步總結一些關于AI智能應用的關鍵特征:

第一,和領域相關的部分是人的活。

這部分拆分未來可能模型能做一部分,但是在衆多變量裡面判斷那部分有價值,比如到底幹什麼,什麼樣才叫合格等估計一直是人的部分。也許方法論部分(比如什麼過程等)未來可以模型幹,但現在模型幹這個費勁。這是邊界問題。

第二,這種應用是按角色來的(角色中心式計算)。比如程式員的角色可能需要調用一大堆工具Git、Python等才能完成自己的職責。但這些最終要變成提示詞(prompt)才能驅動自己的活動。每個角色到底能不能成立,要看圖靈測試2.0能不能過。

很多時候可能實體限制大于智能限制。我們這個例子裡面沒有實體限制(比如把汽車從北京開到蘇州)。

是以智能原生化估計得從這類領域先開始。

第三,需要很多的配套措施。Agent要記住自己說了什麼,要知道目前在幹什麼等。這需要一套完備且繁瑣的機制。寫程式好像就記錄代碼就完了。真正的公司需要彙總業務、财務等各種資料,并且保證資料精度。需要的成本很高,挑戰很大。

第四,什麼時候可以叫完成工作是個問題。産出内容到底合适不合适,幻覺了怎麼辦等,都是關鍵制約。放回到具體場景下智能和想象中的智能好像說的是一個東西,其實是兩碼事。是以之前我們說純數字和幻覺本身不對應過大成本的領域會優先。

過去琢磨事對此進行了一些總結,比如把公司的智能原生式思維提煉為:智能優先,萬物皆、實時回報、中心決策。這在上面這種應用的基礎上可能更好了解。

模型的技術特征決定了需要和它比對的思維模式。

參見:從1到10:AI産品和網際網路産品的核心差異

是普通人的機會麼?

上面這過程看着需要寫代碼驅動,但本質不是一個技術的事。不寫代碼頂多就笨一點,一步一步寫一堆提示詞。代碼是讓整個事串起來更自動一些,影響效率,不影響價值。

所謂的領域,還真不是模型和代碼能概括的事。

也就是說把甕中之腦的能力用起來正需要了解領域的普通人(不是AI科學家)。

是以理論上是普通人的機會,但現在關鍵問題不在這裡,而是你把智能放到自己想的那個場景下,它不一定創造價值。

這是判斷的關鍵。

同時這也暗示了一個很多人都關心的問題的答案:

AI會取代對應的崗位麼?

這是個必然發生的事。

回到基礎公式:智能效能= 模型的智商x現實了解縱深,就會發現這事取決于模型自身的發展,也取決于給它适配的對現實進行了解的系統(Agent)。在上面那個但上面軟體公司裡也還是要人的,隻不過這個角色所需要的能力發生了巨大變化。

小結

最後要強調的是上面這個過程,做着玩是可以的,但不能創業。做領域拆分然後判斷智能高度,這點會看的比較清楚。也就是說現在的技術成熟度不比對合适的商業價值。但這不影響這趨勢本身,模型的基本為此提供了源源不斷的動力。了解這種基礎原型其實提供了一個發現的視角和眼睛。地球上有石油億萬年了,隻有嵌入到工業革命的上下文下它才是财富,是以能看到新現實的新視野還是關鍵的。