前言
相信自AI火热以来 , prompt 这个词听到耳朵都起茧了 , 而之前写prompt只是通过js的模板语法 , 在字符串中动态嵌入字段 ,这种方法, 看似是一种软编码 , 实则在遇到复杂环境的时候 , 就显得过于固定,难以做到复用 ; 在大型项目中 ,难以做到灵活 。
为此我专门到langchain.js的官网上转悠了一圈 , 收获还不少 ~
在langchain.js LLM 的上层应用框架中 , 为我们提供了很多优秀的prompt 的模板 , 以及一些管理方法 , 有利于我们多人开发 , 应对复杂场景 。
本文主要是从宏观上把握langchain.js中的prompt包 , 对所有主要概念cover , 并提供场景化 , 方便日后实际应用可以很好的联想。
除此之外 , 我还会持续学习 , 对常用的api进行demo级的落地 , 对所学进行小型项目实验 , 最后应用结合具体场景开发 ~
废话不多说 , 直接开干 !!!
了解 langchain.js 包的结构
官网:
v03.api.js.langchain.com/index.html
总目录
在 langchain 包下:
在 @langchain 包下
而我们 prompt 在@langchain/coro 包下 , 以下网址直达:
v03.api.js.langchain.com/modules/_la…
官网对于 prompt 的 api 汇总如下 :
对 api 分类有
- classes (类)
- Interfaces (接口)
- Type Aliases (类型别名)
- Variables （变量)
- Functions (函数)
宏观把控
下面宏观把控 langchain.js prompt , 之后我将会对常用方法 独立出文章 ,
并不会对下面所有的 api 面面俱到 , 而是挑选常用且代表 langchain.js 思想的进行整理 ,
我不是 api 翻译器 , 也不是官方文档复读机 , 哈哈哈 ~🤡 , 保证你我源于官网而高于官网
类（Classes）
多种提示模板类
定义了一系列用于不同场景的提示模板类，如
AIMessagePromptTemplate、BaseChatPromptTemplate、PromptTemplate等，涵盖了聊天消息、基础提示、少量示例提示等多种类型。
模板输入类
包含了与提示模板输入相关的类，如
BasePromptTemplateInput、ChatPromptTemplateInput等，用于定义创建提示模板时所需的参数结构。
消息相关类
涉及到消息处理的类，如
ChatMessagePromptTemplate、HumanMessagePromptTemplate、SystemMessagePromptTemplate等，用于构建不同角色的聊天消息提示模板。
其他辅助类
像
MessagesPlaceholder用于在提示模板中占位，PipelinePromptTemplate用于构建管道式提示模板等。
接口（Interfaces）
定义了各种提示模板输入和相关操作的接口规范，确保不同组件在交互时遵循统一的结构和约束。
类型别名（Type Aliases）
创建了一些类型别名，如BaseMessagePromptTemplateLike、Example等，方便在代码中引用和处理特定类型的数据结构。
变量（Variables）
提供了一些默认的格式化映射（DEFAULT_FORMATTER_MAPPING）和解析映射（DEFAULT_PARSER_MAPPING），用于处理提示模板中的字符串插值和解析操作。
函数（Functions）
检查模板有效性函数：checkValidTemplate用于检查提示模板的有效性。
插值和解析函数：interpolateFString、interpolateMustache用于在提示模板中进行字符串插值，parseFString、parseMustache、parseTemplate用于解析模板字符串，renderTemplate用于渲染模板。
代理和工具相关函数：包含了一系列用于创建不同类型代理（如createJsonAgent、createOpenAIFunctionsAgent等）以及与代理执行相关的函数，用于构建和操作基于提示的智能代理。
场景化
作为应用开发者 , 没有能力去在底层搞几下 , 那么就在应用成层做牛马 。作为在应用层的牛马 , 就必须对这些 api 进行场景化 ,使得我们在实际应用的时候 ,能够合理调包调参🤡👈
从官网上 , 我们看到有许多分类 ,那么这些分类有哪些应用场景呢 ?
本篇文章 ,带你从整体上把握一遍 :
多种提示模板类
自然语言处理任务丰富多样，例如在聊天场景中，需要区分不同角色（如用户、系统、AI 助手等）的消息提示，因此有了ChatMessagePromptTemplate、HumanMessagePromptTemplate、SystemMessagePromptTemplate等类，以便根据角色构建合适的提示内容，使对话流程更加自然和清晰。
对于需要少量示例引导模型的任务，FewShotPromptTemplate类提供了相应的支持，通过在提示中加入少量示例，帮助模型更好地理解任务要求，提高回答的准确性。
而PromptTemplate作为基础的提示模板类，适用于一般的文本提示构建，能够满足各种简单到复杂的文本提示需求，如构建一个简单的问题回答提示或一段文本生成的引导提示等。
模板输入类
不同类型的提示模板在创建时需要不同的参数配置，通过定义BasePromptTemplateInput、ChatPromptTemplateInput等模板输入类，明确了每种模板创建所需的参数结构，确保在创建提示模板时传入正确且完整的参数，保证模板的正确性和有效性。这就像为不同类型的建筑（提示模板）提供了各自的蓝图（模板输入类），使得构建过程准确无误。
功能模块化与复用
消息相关类
将消息处理相关的功能封装在特定的类中，实现了功能的模块化。这样，在处理聊天消息提示时，可以方便地复用这些类来构建和管理消息内容，避免了代码的重复编写，提高了开发效率。例如，在多个聊天机器人项目中，如果都涉及到处理用户和系统消息的提示，就可以直接复用这些消息相关类，而无需重新实现消息构建和处理逻辑。
其他辅助类
MessagesPlaceholder类的存在使得在构建提示模板时可以灵活地预留位置，等待后续动态填充信息，增加了提示模板的动态性和通用性。PipelinePromptTemplate类则为构建复杂的提示处理管道提供了支持，能够将多个提示处理步骤串联起来，形成一个完整的处理流程，就像工厂生产线上的多个工序一样，每个工序（提示处理步骤）都有其特定的功能，通过管道（PipelinePromptTemplate）有序地组合在一起，实现对提示信息的深度处理和转换。
标准化与协作
接口（Interfaces)
定义接口规范确保了不同组件在交互时遵循统一的结构和约束。
例如，一个团队中的不同开发者可能负责不同的模块，有的负责构建提示模板，有的负责使用提示模板与语言模型进行交互，接口的存在使得他们之间的工作能够无缝对接。
就像不同国家的火车轨道（组件）需要遵循相同的标准（接口），才能保证列车（数据和操作）在不同轨道间顺利通行，从而实现整个系统的协同工作。
类型别名（Type Aliases）
创建类型别名方便了在代码中引用和处理特定类型的数据结构，提高了代码的可读性和可维护性。
当代码中涉及到复杂的数据结构时，使用类型别名可以使代码更加简洁明了，降低了理解成本。例如，BaseMessagePromptTemplateLike这个类型别名可以在代码中清晰地表示与基础消息提示模板类似的类型，让其他开发者一眼就能明白该变量所代表的数据类型特征。
工具与功能支持
变量（Variables)
提供默认的格式化映射和解析映射变量，简化了提示模板中字符串插值和解析的操作。开发者无需从头编写复杂的插值和解析逻辑，只需使用这些默认的映射，就能快速实现提示模板中变量的替换和处理，节省了开发时间，同时也保证了处理的一致性和准确性。
函数（Functions）
函数的分类满足了提示模板从创建到使用的全流程需求。checkValidTemplate函数在模板创建阶段帮助开发者验证模板的正确性，避免在后续使用中出现错误。
插值和解析函数（interpolateFString、interpolateMustache、parseFString、parseMustache、parseTemplate、renderTemplate）提供了多种方式来处理模板中的字符串，适应不同的模板格式和需求。
例如，有些开发者可能习惯使用 FString 格式的模板，而有些则更倾向于 Mustache 格式，这些函数为他们提供了相应的支持。
代理和工具相关函数则进一步扩展了 LangChain 的功能，使得基于提示的智能代理能够方便地创建和执行。
通过这些函数，可以将提示模板与各种外部工具和服务集成，如创建能够调用特定 API 的代理（createOpenAIFunctionsAgent），从而实现更加智能和强大的自然语言处理功能，如通过代理调用外部知识库或计算服务来获取更准确的答案或执行特定的任务。
总结
了解以上概念 , 以及prompt包下的各种分类 , 有助于我们更好的应用Langchain.js 框架到开发中~ 我将持续对常用的方法进行demo预演 , 等你来玩 ~
