跳转到主要内容

标签(标签)

资源精选(342) Go开发(108) Go语言(103) Go(99) angular(82) LLM(75) 大语言模型(63) 人工智能(53) 前端开发(50) LangChain(43) golang(43) 机器学习(39) Go工程师(38) Go程序员(38) Go开发者(36) React(33) Go基础(29) Python(24) Vue(22) Web开发(20) Web技术(19) 精选资源(19) 深度学习(19) Java(18) ChatGTP(17) Cookie(16) android(16) 前端框架(13) JavaScript(13) Next.js(12) 安卓(11) 聊天机器人(10) typescript(10) 资料精选(10) NLP(10) 第三方Cookie(9) Redwoodjs(9) LLMOps(9) Go语言中级开发(9) 自然语言处理(9) PostgreSQL(9) 区块链(9) mlops(9) 安全(9) 全栈开发(8) ChatGPT(8) OpenAI(8) Linux(8) AI(8) GraphQL(8) iOS(8) 软件架构(7) Go语言高级开发(7) AWS(7) C++(7) 数据科学(7) whisper(6) Prisma(6) 隐私保护(6) RAG(6) JSON(6) DevOps(6) 数据可视化(6) wasm(6) 计算机视觉(6) 算法(6) Rust(6) 微服务(6) 隐私沙盒(5) FedCM(5) 语音识别(5) Angular开发(5) 快速应用开发(5) 提示工程(5) Agent(5) LLaMA(5) 低代码开发(5) Go测试(5) gorm(5) REST API(5) 推荐系统(5) WebAssembly(5) GameDev(5) CMS(5) CSS(5) machine-learning(5) 机器人(5) 游戏开发(5) Blockchain(5) Web安全(5) Kotlin(5) 低代码平台(5) 机器学习资源(5) Go资源(5) Nodejs(5) PHP(5) Swift(5) 智能体(4) devin(4) Blitz(4) javascript框架(4) Redwood(4) GDPR(4) 生成式人工智能(4) Angular16(4) Alpaca(4) 编程语言(4) SAML(4) JWT(4) JSON处理(4) Go并发(4) kafka(4) 移动开发(4) 移动应用(4) security(4) 隐私(4) spring-boot(4) 物联网(4) nextjs(4) 网络安全(4) API(4) Ruby(4) 信息安全(4) flutter(4) 专家智能体(3) Chrome(3) CHIPS(3) 3PC(3) SSE(3) 人工智能软件工程师(3) LLM Agent(3) Remix(3) Ubuntu(3) GPT4All(3) 软件开发(3) 问答系统(3) 开发工具(3) 最佳实践(3) RxJS(3) SSR(3) Node.js(3) Dolly(3) 移动应用开发(3) 低代码(3) IAM(3) Web框架(3) CORS(3) 基准测试(3) Go语言数据库开发(3) Oauth2(3) 并发(3) 主题(3) Theme(3) earth(3) nginx(3) 软件工程(3) azure(3) keycloak(3) 生产力工具(3) gpt3(3) 工作流(3) C(3) jupyter(3) 认证(3) prometheus(3) GAN(3) Spring(3) 逆向工程(3) 应用安全(3) Docker(3) Django(3) R(3) .NET(3) 大数据(3) Hacking(3) 渗透测试(3) C++资源(3) Mac(3) 微信小程序(3) Python资源(3) JHipster(3) 大型语言模型(2) 语言模型(2) 可穿戴设备(2) JDK(2) SQL(2) Apache(2) Hashicorp Vault(2) Spring Cloud Vault(2) Go语言Web开发(2) Go测试工程师(2) WebSocket(2) 容器化(2) AES(2) 加密(2) 输入验证(2) ORM(2) Fiber(2) Postgres(2) Gorilla Mux(2) Go数据库开发(2) 模块(2) 泛型(2) 指针(2) HTTP(2) PostgreSQL开发(2) Vault(2) K8s(2) Spring boot(2) R语言(2) 深度学习资源(2) 半监督学习(2) semi-supervised-learning(2) architecture(2) 普罗米修斯(2) 嵌入模型(2) productivity(2) 编码(2) Qt(2) 前端(2) Rust语言(2) NeRF(2) 神经辐射场(2) 元宇宙(2) CPP(2) 数据分析(2) spark(2) 流处理(2) Ionic(2) 人体姿势估计(2) human-pose-estimation(2) 视频处理(2) deep-learning(2) kotlin语言(2) kotlin开发(2) burp(2) Chatbot(2) npm(2) quantum(2) OCR(2) 游戏(2) game(2) 内容管理系统(2) MySQL(2) python-books(2) pentest(2) opengl(2) IDE(2) 漏洞赏金(2) Web(2) 知识图谱(2) PyTorch(2) 数据库(2) reverse-engineering(2) 数据工程(2) swift开发(2) rest(2) robotics(2) ios-animation(2) 知识蒸馏(2) 安卓开发(2) nestjs(2) solidity(2) 爬虫(2) 面试(2) 容器(2) C++精选(2) 人工智能资源(2) Machine Learning(2) 备忘单(2) 编程书籍(2) angular资源(2) 速查表(2) cheatsheets(2) SecOps(2) mlops资源(2) R资源(2) DDD(2) 架构设计模式(2) 量化(2) Hacking资源(2) 强化学习(2) flask(2) 设计(2) 性能(2) Sysadmin(2) 系统管理员(2) Java资源(2) 机器学习精选(2) android资源(2) android-UI(2) Mac资源(2) iOS资源(2) Vue资源(2) flutter资源(2) JavaScript精选(2) JavaScript资源(2) Rust开发(2) deeplearning(2) RAD(2)

TL;DR:我们正在调整我们的抽象,以便在LangChain中使用除LangChain VectorDB对象之外的其他检索方法。这样做的目的是(1)允许在LangChain中更容易地使用在其他地方构建的检索器,(2)鼓励对替代检索方法(如混合搜索)进行更多实验。这是向后兼容的,所以所有现有的链都应该像以前一样继续工作。然而,我们建议尽快从VectorDB链更新到新的Retrieval链,因为这些链将是未来最受支持的链。

介绍

自从ChatGPT问世以来,人们一直在为自己的数据构建个性化的ChatGPT。我们甚至为此写了一篇教程,然后在几个月前举办了一场关于这方面的比赛。对此的渴望和需求凸显了ChatGPT的一个重要局限性——它不知道你的数据,如果知道的话,大多数人会发现它更有用。那么,你是如何构建一个了解你的数据的聊天机器人的呢?

实现这一点的主要方法是通过一个通常被称为“检索增强生成”的过程。在这个过程中,系统不只是将用户问题直接传递给语言模型,而是“检索”任何可能与回答问题相关的文档,然后将这些文档(以及原始问题)传递到语言模型进行“生成”步骤。

包括我们LangChain在内的大多数人进行检索的主要方式是使用语义搜索。在这个过程中,为所有文档计算一个数字向量(嵌入),然后将这些向量存储在向量数据库(一个为存储和查询向量而优化的数据库)中。然后传入的查询也被向量化,并且检索到的文档是嵌入空间中最接近查询的文档。我们在这里不打算过多详细介绍,但这里有一个关于这个主题的更深入的教程,下面是一个很好地总结了这一点的图表。

Diagram of typical retrieval step

问题

这个过程运行得很好,我们构建的许多组件和抽象(嵌入、向量库)都旨在促进这个过程。

但我们注意到了两个问题。

  • 首先:在如何执行这个检索步骤方面有很多不同的变化。人们希望做语义搜索之外的事情。具体而言:
    • 我们支持两种不同的查询方法:一种只优化相似性,另一种优化最大边际相关性。
    • 用户通常希望在进行语义搜索之前指定元数据过滤器来过滤结果
    • 其他类型的索引,如,已经引起了用户的兴趣
  • 第二:我们还意识到,人们可能会在LangChain之外构建一个检索器——例如,OpenAI发布了他们的ChatGPT检索插件。我们希望让人们尽可能容易地使用他们在LangChain中创建的任何寻回器。

我们意识到我们犯了一个错误——通过以VectorDBQA为中心进行抽象,我们限制了链的使用,使它们很难使用(1)对于想要尝试其他检索方法的用户,(2)对于在LangChain生态系统之外创建检索器的用户。

解决方案

那么我们是如何解决的呢?

在我们最新发布的Python和TypeScript中,我们已经:

  1. 引入了猎犬(Retriever)的概念。检索器应该公开一个具有以下签名的get_relevant_documents方法:def get_relevant_documents(self, query: str) -> List[Document]。这是我们对寻回犬的唯一假设。请参阅下面关于此界面的更多信息。
  2. 将我们所有使用VectorDB的链更改为现在使用Retriever。VectorDBQA现在是RetrievalQA,ChatVectorDBChain现在是ConversationalRetrievalChain,等等。请注意,向前看,我们有意使用Conversational前缀来指示链正在使用内存,而Chat前缀则表示链正在使用聊天模型。
  3. 添加了非LangChain检索器的第一个实例-ChatGPT检索插件。这是OpenAI昨天开源的一个模块,旨在帮助公司公开检索端点以连接到ChatGPT。注意:就所有意图和目的而言,ChatGPT检索插件的内部工作方式与我们的VectorStores非常相似,但我们仍然非常兴奋能够将其集成为一种突出现有新灵活性的方式。

在Retriever接口上进行扩展:

  • 我们有目的地只需要一个方法(get_relevant_documents),以便尽可能宽松。我们(还)不需要任何统一的方法来构建这些检索器。
  • 我们有目的地将query:str作为唯一的参数。对于所有其他参数(包括元数据过滤),这应该作为参数存储在检索器本身上。这是因为我们预计检索器通常嵌套在链中,并且我们不希望在其他参数周围有铅垂。

这一切的最终目标是让替代检索器(除了LangChain VectorStore)更容易在链和代理中使用,并鼓励替代检索方法的创新。

问答

Q: 索引和检索器有什么区别?

A: 索引是一种支持高效搜索的数据结构,检索器是使用索引来查找和返回相关文档以响应用户查询的组件。索引是检索器执行其功能所依赖的关键组件。

Q: 如果我以前在VectorDBQA链(或其他VectorDB类型的链)中使用VectorStore,那么我现在在RetrievalQA链中使用什么?

A: 您可以使用VectorStoreRetriever,您可以通过执行vectorstore.as_retriever()从现有的vectorstore创建它

Q: VectorDBQA链(或其他VectorDB类型的链)是否仍然存在?

A: 是的,尽管我们将不再专注于此。预计未来的任何开发都将在RetrievalQA链上完成。

Q: 我能为library贡献一种新的检索方法吗?

A: 是的!我们正是为此目的启动了一个新的langchain/retrievers模块

Q: 现实世界中有哪些这样的例子?

A: 主要的一个是比你的文件更好的问答。然而,如果开始摄取并检索以前的信息,这可以被认为是人工智能更好的长期记忆。