AutoGenPromptTesting下載 - AutoGenPromptTesting源代碼下載

AutoGenPromptTesting

Ai源碼

1.0.0

下載

使用本地LLM時迅速測試Autogen

該存儲庫是我用於測試提示的操場，可從本地LLM產生合適的響應。由於它是一個操場，因此結構不佳，因此請隨時提出任何問題。 Autogen Discord是討論的好地方，請參閱其中的＃Alt-Models通道。

我正在研究Autogen工作流程（從代碼庫到代理說明）中需要量身定制的積分，以適應當地的LLM，這些LLM不如AI的Chatgpt這樣的大型私人型號。

目前使用Tevslin創建的“群體聊天”辯論場景（請參閱辯論。下一個代理/角色始終如一。這是一個很好的測試，因為它涉及LLM了解代理的順序，審查辯論在哪裡並確定下一個代理商。我們幾乎可以以圓形旋轉格式或有限狀態機器（我們可以與誰交談）來執行此操作，但是能夠提示LLM選擇正確的，下一個代理商很重要。

我將在此讀書中提出任何發現。請注意，這正在不斷發展，我只是一個試圖使事情起作用的人嗎？

我正在嘗試的LLM

Llama2 13B聊天
MISTRAL 7B V0.2指令
Mixtral 8x7b V0.1指令（Q4）
神經聊天7b
OpenHermes 7b Mistral v2.5（Q6）
ORCA 2 13B
PHI-2
Phind Codellama 34B V2
QWEN 14B聊天（Q6）
太陽能10.7b指令
yi-34b聊天（Q3）

在針對Autogen庫進行測試時，我正在使用Ollama，並在通過AutoGenstudio進行測試時使用Litellm。

我目前正在測試的代碼是揚聲器選擇 - 測試回合。

在辯論挑戰中選擇演講者的當前表現：

	揚聲器正確選擇
✅	所有5個正確
？	4 of 5正確
	3或更少正確
？	沒有通過

寬桌子 - 滾動 - >

步驟1內容	選擇揚聲器	降低上下文	Phind-Codellama：34B-V2	混合8x7b（Q4）	OpenHermes：7b-Mistral-V2.5-Q6_K	orca2：13b-q5_k_s	太陽能：10.7b-instruct-v1-q5_k_m	Neural-Chat：7b-V3.3-Q6_K	Llama2：13b-chat	QWEN：14B-CHAT-Q6_K	MISTRAL：7b-Instruct-Q6_K	PHI-2
原來的	原來的	沒有任何										？
原來的	強調，順序，簡潔	總結	✅	✅	✅		？					？
原來的	強調，順序，簡潔	沒有任何		✅	✅		？					？
強調秩序	強調，順序，簡潔	沒有任何	✅	？	✅		？	？	？			？
強調秩序	強調，順序，簡潔	總結	✅	？	✅		？	？	？			？
強調 +示例	強調，順序，簡潔	沒有任何	✅	✅	？	？		？	？			？
強調 +示例	強調，順序，簡潔	總結	✅	✅	？	？		？	？			？
原來的	原來的	只有揚聲器名稱	✅				✅					？
強調 +示例	強調，首都，推理，沒有辯論	前300個字符	？	✅		？					？	？
強調秩序	強調，順序，簡潔	前300個字符	？	✅			？	？				？
強調秩序	強調，順序，簡潔	前100個字符和名稱	✅	？			？			？		？
強調秩序	強調，順序，簡潔	只有揚聲器名稱	？	✅				？		？		？
強調秩序	強調，首都，推理，沒有辯論	前300個字符		？		✅	？					？
強調 +示例	強調，順序，簡潔	前300個字符		✅		？					？	？
強調 +示例	強調，順序，簡潔	只有揚聲器名稱	？	✅					？			？
強調 +示例	強調，首都，單詞回复	總結			？	✅	？					？
強調 +示例	強調，順序，簡潔	前100個字符和名稱	？	✅								？
強調 +示例	強調，首都，單詞回复	沒有任何				✅	？					？
強調 +示例	強調，首都，單詞回复	只有揚聲器名稱					✅					？
強調 +示例	強調，首都，推理，沒有辯論	沒有任何	？	？	？	？	？					？
強調 +示例	強調，首都，推理，沒有辯論	總結	？	？	？	？	？					？

獲獎者：

Phind-Codellama：34B-V2
混音：8x7b-instruct-v0.1-q4_k_m
OpenHermes：7b-Mistral-V2.5（Q6）

到目前為止的學習：

LLMS不同

LLM之間的結果毫不奇怪。但是，調整提示正在改變他們獨立的行為方式 - 例如，在提示中更改一兩個單詞將意味著產生正確結果的Mistral 7b會產生出乎意料的事物，但同樣的更改意味著Solar 10.7b，這不是產生我想要的，突然會產生正確的結果。

因此，在此階段，我相信我們需要量身定制許多提示（我們可以通過代理說明和系統消息控制的提示，直到諸如揚聲器選擇之類的基礎提示），以適合我們正在使用的LLM 。直到可以達到最低LLM推理標準之前。

溫度= 0

我很快了解到，要獲得一致的結果，至少對於揚聲器選擇提示，我必須將溫度設置為零（可能以較低的數字而不是零作用）。儘管即使在零時，響應有時也會有所不同，它們通常是一致的。

能夠在自動基因中設置模型溫度的能力對於這些小的LLM很重要。

上下文長度

隨著聊天消息的數量不斷增長，模型也會停止產生良好的響應的機會。有些人，例如具有2K上下文長度的PHI-2，將停止在我的測試中進行辯論小組聊天的一半。其他的，包括帶有32K上下文窗口的混音8x7b，當上下文長度減少時（據此，內容較長之前）顯示出改善。

一個例子是，使用Mixtral，當傳遞給Mixtral的完整聊天消息少於8,700個字符（不代表，我無法得到這個數字）時，它將返回正確的答案（始終延長到該字符計數）。當它超過8,700個字符時，它不會遵循指示，而不是返回下一個演講者的名字，而是將其作為他們辯論。這是一個一致的問題，因為長度持續增長超過8,700。我想其他模型此切換點還會降低。

目前，似乎沒有一種壓縮對話歷史記錄的機制，但是我認為這對於隨著更多聊天而保持完整聊天的上下文可能會很有用。

減少聊天消息長度

在最小化上下文長度的挑戰中，我想到了兩個選擇：

如果我們不需要說話者選擇，請刪除代理商的消息的內容
總結代理商消息的內容，因此我們保留一般上下文 - 這與一些消息一起起作用，但是隨著消息數量的增加，摘要可能仍然太多。

我想，我們可以將這兩個選項結合在一起，刪除舊消息的內容，並彙總較新的消息。

對於我正在進行的揚聲器選擇測試，刪除上下文並彙總了代理消息既有效又產生了正確的結果。這是有希望的。

揚聲器選擇（自動模式）在小組聊天中

我一直專注於測試這一點，因為對正確選擇代理至關重要。這項任務主要是在基礎自動源代碼中完成的，該任務是針對打開AI的Chatgpt而定制的。提示也可能與其他非常大型型號一起使用。但是，控制此提示對於為我們較小的本地LLM提供特定方向是必要的。

默認提示為

 You are in a role play game. The following roles are available:n{self._participant_roles(agents)}.nnRead the following conversation.nThen select the next role from {[agent.name for agent in agents]} to play. Only return the role.

對於我對辯論工作流的測試，我不斷地量身定制提示，並說明Mixtral 8x7b的外觀是：

 Read the above conversation and select the next role, the list of roles is ['Debate_Moderator_Agent', 'Affirmative_Constructive_Debater', 'Negative_Constructive_Debater', 'Affirmative_Rebuttal_Debater', 'Negative_Rebuttal_Debater', 'Debate_Judge']. What is the next role to speak, answer concisely please?

有趣的是，即使是一個小調整，例如更改（在上面的文本中）

 answer concisely please

到

 return only the name of the role

更改了對混音的不正確的反應，但對駱駝13B的響應更改為正確的響應。

誰在說誰？

通過辯論測試，有一條介紹的聊天消息（這是一個角色扮演遊戲，...），然後為每個辯論者提供了聊天消息。我們將所有這些聊天消息傳遞給LLM，以確定揚聲器選擇過程中的下一個揚聲器。

每個辯論者的聊天消息都有內容（他們的辯論響應），角色（“用戶”）和名稱（其代理名稱），如這樣：

    {
        "content": "<a whole lot of content here.>",
        "role": "user",
        "name": "Affirmative_Constructive_Debater",
    },

由於所有這些都傳遞給LLM，我認為它將使用該name鍵/值來知道該消息來自哪個代理。

有趣的是，如果我為每個消息的內容添加以下內容

 I am <the debater's name here>. <then the original content goes next>

... Mixtral在接聽並選擇下一個經紀人的人方面要好得多。因此，在每個代理商的消息開始時明確插入此此內容可能是有利的，以便我們確定LLM知道代理人是誰。或者，至少在這種情況下，代理的名稱對於確定序列很重要。

純文本輸出

大多數模型都返回了純文本響應，這對於將代理名稱與從LLM返回的文本匹配至關重要。

但是，由於它是我要使用的主要模型，因此Mixtral似乎在大多數情況下似乎都在降級（？）格式中提供了響應。因此，如果代理人被命名

 Negative_Constructive_Debater

它可能會返回

 Negative_Constructive_Debater

或者

 Negative Constructive Debater

這將使Autogen與代理商的名字匹配。

我試圖更改提示以獲取混音以提供純文本輸出，但無法始終如一地這樣做。

也許這裡的策略不是使用下劃線，儘管我認為已經提到要避免代理名稱中的空間並使用下劃線，因此值得解決這一問題。

更改匹配代碼以適應_和下劃線的空間對於支持可能將其混合的本地LLM有很長的路要走。

那麼，我認為最好的本地LLM是什麼？

作為警告，我很早就進行了測試，並且我只是在揚聲器選擇提示上進行測試。儘管這對於多代理流程至關重要，但LLMS（質量響應，代碼生成，呼叫等）還有許多其他方面，我甚至沒有觸摸過。

因此，下面我的註釋是關於LLM的早期測試，選擇正確的下一個代理並返回其名稱。我將它們按照我的優先順序。

最後，其中很多是在提出技能，我不是專家:)。

LLM	想法
Mixtral 8x7b V0.1指令（Q4）	作為最大的模型，我希望這比其他模型更好地處理方向。我的經驗是，它提供了一致的響應，並且通過一些迅速的更改，您可以將其糾纏以獲得所需的結果。它確實有一個奇怪的怪癖，因為它有時會以降級格式做出響應。
MISTRAL 7B V0.2指令	最初，這提供了最佳響應，純文本結果以及在不脫離課程的情況下返回單個代理名稱的能力。提示表明，這對提示更改非常敏感。不過，它並不總是理解指示，遠不如混音
Llama2 13B聊天	命中和錯過，當它到底是完美的時，否則不是。更及時的調整可能在這里工作。
太陽能10.7b指令	隨著提示的調整，這變得越來越一致
神經聊天7b	與Llama 13B相似，有時很棒，但除了其他方面都沒有
OpenHermes 7b Mistral v2.5（Q6）	在一次測試中，它是完美的，因為其餘的所有轟炸。發現它不能很好地遵循指示。
ORCA 2 13B	只完成了一個測試，其餘的都沒有很好地遵循指示
QWEN 14B聊天（Q6）	我以前從未使用過這種模型，並且希望它從未通過測試，並且遵循指示不是其強項。
PHI-2	不幸的是，該模型支持的上下文長度很快就用完了。此外，它確實沒有準確地遵循指示。
Phind Codellama 34b	出人意料的好！用混合。但是，它說這不會辯論！
yi-34b聊天（Q3）	這讓我感到驚訝，這確實是最糟糕的。我將其排在PHI-2以下，因為它太大了，無法在以下方向上如此糟糕。也許指示 /其他版本會更好。