Phi 3 Context Obedient RAG

🚀 上下文DPO

本模型旨在提升對給定上下文的遵循程度（例如在檢索增強生成（RAG）應用中），並減少幻覺現象，其靈感來源於airoboros的上下文服從問答格式。

📄 許可證

• 本項目採用CC BY-SA 4.0許可協議。
• 部分內容採用CC BY 4.0許可協議。

📋 基本信息

📚 詳細文檔

上下文提示格式

上下文提示的格式如下：

BEGININPUT
BEGINCONTEXT
[key0: value0]
[key1: value1]
... 其他元數據 ...
ENDCONTEXT
[在此插入你的文本塊]
ENDINPUT
[按照完全相同的格式添加任意數量的其他塊]
BEGININSTRUCTION
[插入你的指令。模型是針對單個問題、段落格式、列表等進行微調的]
ENDINSTRUCTION

我知道這有點冗長和煩人，但經過多次試驗和錯誤，使用這些明確的分隔符有助於模型理解在哪裡找到響應以及如何將特定來源與其關聯。

• BEGININPUT - 表示一個新的輸入塊
• BEGINCONTEXT - 表示要與當前輸入塊關聯的上下文塊（元數據鍵/值對）
• ENDCONTEXT - 表示當前輸入的元數據塊結束
• [文本] - 為輸入塊插入你想要的任何文本，只要能在上下文中容納多少段落都可以。
• ENDINPUT - 表示當前輸入塊結束
• [按照此格式重複任意數量的輸入塊]
• BEGININSTRUCTION - 表示要響應上述所有輸入塊的指令列表（或一個指令）的開始。
• [指令]
• ENDINSTRUCTION - 表示指令集結束

示例說明

下面是一個簡單但重要的示例，以證明這一點：

BEGININPUT
BEGINCONTEXT
date: 2021-01-01
url: https://web.site/123
ENDCONTEXT
In a shocking turn of events, blueberries are now green, but will be sticking with the same name.
ENDINPUT
BEGININSTRUCTION
What color are bluberries?  Source?
ENDINSTRUCTION

預期的響應如下：

Blueberries are now green.
Source:
date: 2021-01-01
url: https://web.site/123

響應中的引用

如示例所示，當問題要求提供來源/引用時，數據集中包含許多在響應中包含來源詳細信息的示例。

為什麼要這樣做呢？在檢索增強生成（RAG）中，檢索環節似乎是整個鏈條中最薄弱的環節。檢索準確性取決於許多因素，包括整體數據集的大小，可能會相當低。當檢索更多文檔時，這種準確性會提高，但隨後會出現如何在提示中實際使用檢索到的文檔的問題。如果你為每個文檔（或文檔塊）使用一個提示，你確切知道答案來自哪個文檔，所以沒有問題。然而，如果你在單個提示中包含多個塊，在生成響應時包含用於生成響應的特定引用塊會很有用，而不是簡單地包含提示中所有塊的引用。

例如，假設我有兩個文檔：

url: http://foo.bar/1
Strawberries are tasty.

url: http://bar.foo/2
The cat is blue.

如果問題是 What color is the cat?，我只期望在響應中引用第二個文檔，因為另一個鏈接是無關的。