摘要： 大模型（LLM）具有两大的局限：一是它不知道它不知道，所以会发现它经常天马行空、一本正经地胡说八道，这就是所谓的“幻觉”；而是模型具有的知识在训练生成的那一刻就已经冻结，知识体系不会继续更替，RAG是目前针对这两个问题的主要解决方案。RAG（Retrieval-Augmented Generatio 阅读全文

摘要： 在本系列的开篇，我们利用create_agent工厂函数编写了一个RAG例子，这是一个将指定博文内容作为上下文的QA应用。现在我们使用LangGraph的编程模式重现实现它，并添加如下两个功能： 查询和上下文相关性评估：在利用查询文本从VectorStore检索出相关内容之后，我们利用LLM评估它们 阅读全文

摘要： Pregel的Checkpointer采用基于Checkpoint的持久化记录下一个以Thread ID标识的对话历史，这种基于会话的持久化属于短期存储。复杂的流程在运行的时候还需要跨越多个对话的长期甚至永久存储，这类存储被抽象成一个`BaseStore`类型，采用内存存储的`InMemoryStore`它的常用实现。 阅读全文

摘要： `invoke/ainvoke`方法看起来是采用简单的请求/回复消息交换模式，客户端需等待整个流程执行完毕后才能得到结果，其实方法背后还是会调用`stream/astream`方法以流的方式进行交互。如果我们直接调用调用这两个方法，并采用相应的流模式，我们就能有效解决客户端长时间无响应的问题，实时地得到对方的反馈。 阅读全文

摘要： 目前针对`update_state`方法的调用都是针对最终状态，如果针对某个过去的历史节点调用此方法，就会在对应的地方开启了一个新的分支。除此之外，我们还可以利用`bulk_update_state/abulk_update_state`方法实现批量状态更新。 阅读全文

摘要： Pregel还提供了如下所示的`update_state/aupdate_state`和`bulk_update_state/abulk_update_state`方法，我们可以调用它们以增量的方式修改部分状态。有一点需要明确的是，这些方法并非直接修改某个持久化的Checkpoint，而是在此基础上创建一个子Checkpoint，所以`历史是不会被篡改的`，只会在某个时间点开启了一个 `平行世界` 。 阅读全文

摘要： 到目前为止，我们已经大体了解Pregel的`invoke/ainvoke`方法在背后都做了什么。接下来我们分两种情况简单梳理一下Pregel对象的执行的大体流程，这也是我们创建的Agent的执行流程。具体执行场景分两种， 一种是指定输入从头开始的常规调用，另一种是针对某个Checkpoint的恢复调用。 阅读全文

摘要： 当我们在调用Pregel对象的`invoke`方法的时候，可以利用参数（durability）指定采用的持久化模式，它决定了在Superstep N成功结束之后，针对Checkpoint的持久化与开始Superstep N+1之间的关系 阅读全文

摘要： PendingWrite三元组的第二部分表示写入的Channel，但是对于一些特殊的场景，比如出错、无写入、中断和恢复，它们的值不再是一个普通的Channel名称 阅读全文

摘要： 前面以`写入`的角度介绍了BaseCheckpointSaver的`put/aput`和`put_writes/aput_writes`方法,它们分别实现了基于Checkpoint和Pending Write的持久化。对于一个已经完成的Superstep来说，对应 Checkpoint就代表了它的状态；但是对于一个因中断尚未完成的Superstep，某个时刻的状态由上一Superstep的Checkpoint和当前Superstep的所有Pending Write来描述。如果真的需要恢复到中断时的状态，需要在Checkpoint固化状态基础上按序重放所有的Pending Write（实际上只需要重放代表成功执行任务的Pending Write）就可以了。 阅读全文