LangChain记录
前言
LLM 不管是 GPT 还是 BERT，有且只有一个核心功能，就是预测你给定的语句的下一个词最有可能是什么（靠Prompt激发），除此之外的工作，比如解析 PDF、比如对话式搜索、甚至拿过来一个大任务分解、创建子任务，最终完成，都需要有一整套的工具来把核心功能包装，便于开发人员搭积木，这个工具就是 LangChain。
LangChain底层就是Prompt、大模型API、以及三方应用API调用三个个核心模块。对于LangChain底层不同的功能，都是需要依赖不同的prompt进行控制。基于自然语言对任务的描述进行模型控制，对于任务类型没有任何限制，只有说不出来，没有做不到的事情。
PS：看LangChain的感受就是：遇事不决问LLM。这跟常规的工程项目 严丝合缝的逻辑 + ifelse控制流非常不一样。 比如外挂知识库，LLM 不只用于最后一步 对topk 匹配的chunk 做一下润色给出anwser，前期的文档切分、存储、history的存储、选用，用户query的意图识别、转换都可能用到LLM。
OPENAI接口
LangChain 本身不提供LLM，本质上就是对各种大模型提供的 API 的套壳，是为了方便我们使用这些 API，搭建起来的一些框架、模块和接口。因此，要了解 LangChain 的底层逻辑，需要了解大模型的 API 的基本设计思路。重点有两类模型：Chat Model 和 Text Model（当然，OpenAI 还提供 Image、Audio 和其它类型的模型），Chat 模型和 Text 模型的调用是完全一样的，只是输入（input/prompt）和输出（response）的数据格式有所不同
- Text Model，文本模型
- Chat Model，聊天模型，用于产生人类和 AI 之间的对话，有两个专属于 Chat 模型的概念，一个是Message，一个是role。每个Message都有一个 role（可以是 system、user 或 assistant）和 content（消息的内容）。系统消息设定了对话的背景（比如你是一个很棒的智能助手），然后用户消息提出了具体请求。
- system：系统消息主要用于设定对话的背景或上下文。这可以帮助模型理解它在对话中的角色和任务。例如，你可以通过系统消息来设定一个场景，让模型知道它是在扮演一个医生、律师或者一个知识丰富的 AI 助手。系统消息通常在对话开始时给出。PS: prompt技巧之一就是设定角色
- user：用户消息是从用户或人类角色发出的。它们通常包含了用户想要模型回答或完成的请求。用户消息可以是一个问题、一段话，或者任何其他用户希望模型响应的内容。
- assistant：助手消息是模型的回复。例如，在你使用 API 发送多轮对话中新的对话请求时，可以通过助手消息提供先前对话的上下文。然而，请注意在对话的最后一条消息应始终为用户消息，因为模型总是要回应最后这条用户消息。
- observation： 比如chatglm3 为了强化Agent能力，新增了observation role 表示其内容是由tool返回的。
Completion response = openai.Completion.create(model="text-davinci-003",prompt="Say this is a test") （TEXT IN TEXT OUT）
{
"id":xx,
"object":"text_completion",
"created": xx,
"model": "text-davinci-003",
"choices": [
{
"text": "Yes, this is a test.",
"index": 0,
"logprobs": null,
"finish_reason": "stop",
}
}Chat Model响应（MESSAGE IN MEESAGE OUT）
{
'id': 'chatcmpl-2nZI6v1cW9E3Jg4w2Xtoql0M3XHfH',
'object': 'chat.completion',
'created': 1677649420,
'model': 'gpt-4',
'usage': {'prompt_tokens': 56, 'completion_tokens': 31, 'total_tokens': 87},
'choices': [
{
'message': {
'role': 'assistant',
'content': '你的花店可以叫做"花香四溢"。'
},
'finish_reason': 'stop',
'index': 0
}
]
}Completions API 主要用于补全问题，用户输入一段提示文字，模型按照文字的提示给出对应的输出。
| model | 必选参数 | 调用的Completions模型名称，如text-davinci-003、text-curie-001等，不同模型参数规模不 同；在大模型领域，（就OpenAI提供的A、B、C、D四大模型来看）参数规模越大、越新版本的模型效果更好（费用也更高） |
| prompt | 必选参数 | 提示词 |
| suffix | 可选参数 | 默认为空，具体指模型返回结果的后缀 |
| max_tokens | 可选参数 | 默认为16，代表返回结果的token数量 |
| temperature | 可选参数 | 取值范围为0—2，默认值为1。参数代表采样温度，数值越小，则模型会倾向于选择概率较高的词汇，生成的文本会更加保守；而当temperature值较高时，模型会更多地选择概率较低的词汇，生成的文本会更加多样 |
| top_p | 可选参数 | 取值范围为0—1，默认值为1，和temperature作用类似，用于控制输出文本的随机性，数值越趋近与1，输出文本随机性越强，越趋近于0文本随机性越弱；通常来说若要调节文本随机性，top＿p和temperature两个参数选择一个进行调整即可；更推荐使用temperature参数进行文本随机性调整 |
| n | 可选参数 | 默认值为1，表示一个提示返回几个Completion |
| stream | 可选参数 | 默认值为False，表示回复响应的方式，当为False时，模型会等待返回结果全部生成后一次性返回全部结果，而为True时，则会逐个字进行返回 |
| logprobs | 可选参数 | 默认为null，该参数用于指定模型返回前N个概率最高的token及其对数概率。例如，如果logprobs设为10，那么对于生成的每个token，API会返回模型预测的前10个token及其对数概率； |
| echo | 可选参数 | 默认为False，该参数用于控制模型是否应该简单地复述用户的输入。如果设为True，模型的响应会尽可能地复述用户的输入 |
| stop | 可选参数 | 该参数接受一个或多个字符串，用于指定生成文本的停止信号。当模型生成的文本遇到这些字符串中的任何一个时，会立即停止生成。这可以用来控制模型的输出长度或格式； |
| presence_penalty | 可选参数 | 默认为0，取值范围为［—2，2］，该参数用于调整模型生成新内容（例如新的概念或主题）的倾向性。较高的值会使模型更倾向于生成新内容，而较低的值则会使模型更倾向于坚持已有的内容，当返回结果篇幅较大并且存在前后主题重复时，可以提高该参数的取值； |
| frequency_penalty | 可选参数 | 默认为0，取值范围为［—2，2］，该参数用于调整模型重复自身的倾向性。较高的值会使模型更倾向于避免重复，而较低的值则会使模型更可能重复自身；当返回结果篇幅较大并且存在前后语言重复时，可以提高该参数的取值； |
| best_of | 该参数用于控制模型的生成过程。它会让模型进行多次尝试（例如，生成5个不同的响应），然后选择这些响应中得分最高的一个； | |
| logit_bias | 该参数接受一个字典，用于调整特定token的概率。字典的键是token的ID，值是应用于该token的对数概率的偏置；在GPT中可以使用tokenizer tool查看文本Token的标记。一般不建议修改； | |
| user | 可选参数 | 使用用户的身份标记，可以通过人为设置标记，来注明当前使用者身份。 |
Chat模型升级的核心功能是对话， 它基于大量高质量对话文本进行微调，能够更好的理解用户对话意图，所以它能更顺利的完成与用户的对话（大语言模型本质上都是概率模型，根据前文提示进行补全是⼤语⾔模型的原始功能，而对话类的功能则是加⼊额外数据集之后训练的结果）。
ChatCompletion.create函数的详细参数和Completion.create函数相比发生了以下变化：
- 用messages参数代替了prompt参数，使之更适合能够执行对话类任务
- 新增functions和function_call参数，使之能够在函数内部调用其他工具的API
- 其他核心参数完全一致，例如temperature、top_p、max_tokens、n、presence_penalty等参数的解释和使用方法都完全一致，且这些参数具体的调整策略也完全一致
- 剔除了best_of参数，即Chat模型不再支持从多个答案中选择一个最好的答案这一功能
所有语言模型，包括用于聊天的模型，都是基于线性序列的标记进行操作，并没有内在的角色处理机制。这意味着角色信息通常是通过在消息之间添加控制标记来注入的，以表示消息边界和相关角色。以单轮对话为例：
适配前--单轮对话：
user：我今早上吃了炒米粉。
assistant：炒米粉在广东是蛮常见的早餐，但是油太多，可以偶尔吃吃。
适配后--单轮对话：
<s><intp>我今早上吃了炒米粉。</intp> [ASST] 炒米粉在广东是蛮常见的早餐，但是油太多，可以偶尔吃吃。[/ASST] eos_token这里除了区分user和 assistant加的special token 以外，必须要添加的是eos_token，必须要让模型知道什么时候next token生成结束，如果没有终止符，模型会陷入推理的无限循环。
不幸的是，目前还没有一个标准来确定使用哪些标记，因此不同的模型使用的格式和控制标记都可能大相径庭。聊天对话通常表示为字典列表，每个字典包含角色和内容键，表示一条单独的聊天消息。聊天模板是包含Jinja模板的字符串，用于指定如何将给定模型的对话格式化为一个可分词的序列。通过将这些信息存储在分词器中，我们可以确保模型以其期望的格式获取输入数据。对于一个模型来说，chat template 存储在tokenizer.chat_template 属性上（这个属性将保存在tokenizer_config.json文件中），如果chat template没有被设置，对那个模型来说，默认模版会被使用。
LLM模型层
一次最基本的LLM调用需要的prompt、调用的LLM API设置、输出文本的结构化解析（output_parsers 在 prompt 中插入了需要返回的格式说明）等。从 BaseLanguageModel 可以看到模型层抽象接口方法predict 输入和输出是str，也就是 TEXT IN TEXT OUT。PS：底层Transformer比如 chatglm原输出不是直接str，langchain中要求模型返回必须是str的结果，因此 Transformers.Model 与 langchain.llm 要有一个适配。
# BaseLanguageModel 是一个抽象基类，是所有语言模型的基类
class BaseLanguageModel(...):
# 基于用户输入生成prompt
@abstractmethod
def generate_prompt(self,prompts: List[PromptValue],stop: Optional[List[str]] = None,...) -> LLMResult:
@abstractmethod
def predict(self, text: str, *, stop: Optional[Sequence[str]] = None, **kwargs: Any ) -> str:
@abstractmethod
def predict_messages(self, messages: List[BaseMessage],) -> BaseMessage:
# BaseLLM 增加了缓存选项, 回调选项, 持有各种参数
class BaseLLM(BaseLanguageModel[str], ABC):
1. 覆盖了 __call__ 实现 ==> generate ==>