# \[中文]Langtorch one pager Langtorch是一个帮助你开发大语言模型应用的Java框架。从设计上遵循可重复使用，易组合，Fluent style的特点。它能够帮助你开发包含大预言模型的工作流或者pipeline。 ### Processor 在langtorch中，我们引入了processor的概念。实际上，processor是一个langtorch中最小计算单元的容器。processor产生的response既可能来自大语言模型，比如OpenAI的Rest API, 也可能是一个deterministic的function.

processor是一个interface，里面包含了两个functions: run() 和 runAsync()。只要实现了这两个function，我们都可以称之为processor 比如processor实际上可以是发送http request给open ai来调用它gpt的模型并产生回答。也可以是一个计算器的function，input是1+1， output就是2 通过这个方式，我们能够很方便的添加一个processor，比如即将公测的Google PALM 2的API 同时，在我们把不同的processor chain在一起的时候能够利用规避一些llm的缺点。比如，当我们要实现余个chatbot的话，如果用户问到一个数学问题，那我们可以将这个数学问题通过llm的能力parse成我们计算器的一个输入从而得到一个准确的答案，而不是让llm自己直接得出结论。 Note: processor是langtorch中最小的计算单元，所以一个processor一般只被允许拥有一种能力。比如处理text completion的能力，或者处理chat completion的能力，或者根据prompt生成出图像的能力。如果需求是比较复杂的，比如先通过text completion生成出一个公司的slogan，再根据slogan来生成图片。应该通过chaining不同的processor来完成，而不是在一个processor内完成所有的事情。\
### Capability Processor正如上面提到的是一个计算单元的最小容器，面对不同的情况时，processor往往是不足以应付所有的情况。我们需要增强processor！这里我们就引入了Capability这个概念。如果说processor是内燃蒸汽机，那capability可以是基于蒸汽机的蒸汽火车，也可以是基于蒸汽机的发电机。

试想一下，你现在实现一个chatbot，如果processor是基于openai的api，并将每次用户的输入发送给openai gpt4的模型并返回，这样的chatbot用户体验会是怎样？

原因是chatbot并没有将聊天记录嵌入进去。那么在capability中，我们就可以加入memory(一个简单的memory的实现方式就是将所有对话记录放进发给openai的request中)。 ### Workflow(chaining Capabilities) 为了让capability之间的组合更加容易，我们引入了Node Adapter这个概念。而不同capability组成的我们称为Capability graph。但我们严格规定capability graph必须是一个DAG（单向图），即没有cycle。

### Node Adapter

Node adapter 主要是用做capability graph的validation和优化。node adapter包裹了capability，此外还包括一些capability graph的信息。比如现在node的全局独特id是什么，接下来的node是哪些，等。