AI原生应用产品讨论-对话类

一眨眼，距离开始学习AI已经过去半年多了。这半年将自己无限地横向地拓宽，看技术原理，也看场景应用和商业模式。打算有意识地收束到产品上，对标星的开源项目以及用过的产品、平台，分专题做对比，然后延伸和深入进行讨论。这篇作为开始。
对比的目的，不是为了地找出各个项目的不同然后粗暴地评价某个功能的好坏，而是通过尝试理解设计背后的原因以及它会对整体产品带来的影响，寻找可借鉴的点。最重要的是，结合实际场景，探讨不同形态的AI原生应用究竟该如何满足用户的场景化需求。

对话类项目/产品的共性是：模型能力和集成的其他辅助服务，主要通过对话界面（LUI/CUI）提供给用户。从这类项目开始的原因很简单：基于LLM本身的属性以及chatGPT打的样，对话界面成为了很多个人和团体对LLM部署和应用的直觉选择。功能简单的，聊天界面仅有输入和输出气泡，复杂的，则基于场景在输入和输出分开做对应的优化。
这里将对比的项目如下：

介绍

github上此类的项目很多，这里仅列出了5个，更多可见：https://github.com/stars/Revellen/lists/chatui

LIbreChat

页面快照

功能特性：

模型服务商自定义配置：默认支持OpenAI，Azure,，Anthropic，Google，支持基于ollama配置本地模型服务，或基于其他符合OpenAI api标准的模型服务创建自定义endpoint。
多种文件类型支持：支持添加包括pdf、docx、xlsx、png在内的多种格式文件作为对话附件
语音输入及输出：支持语音输入及输出
对话分支：可在对话中的任何一个节点进行fork，并基于此前的对话历史重起对话分支
移动端页面适配

anythingLLM

页面快照

功能特性：

模型服务商自定义配置：默认支持OpenAI，Azure,，Anthropic，Google等直接服务商；支持huggingface，Groq，OpenRouter等模型托管或服务转发平台；支持基于ollama和lm studio的本地模型服务，此外，支持基于其他符合OpenAI api标准的模型服务创建自定义模型服务端点。
快捷对话指令及agent唤起：可通过“/”调用快捷指令，通过“@ agent” 唤起agent
agent支持：自带长期记忆单元，支持的agent能力配置包括网页读取、网页搜索、图表生成、数据库查询（不是所有模型都可配置为agent模型基础）
RAG支持：自带embedding模型，也可自定义embedding服务商；支持设置chunksize和overlap值；提供多种向量数据库选择（LanceDB、ChromaDB、Pinecone等）
对话历史及系统log查看：可在统一界面查看所有历史对话记录，可查看系统日志
本地化数据存储：对话及embedding结果保留在本地，且所有的事件不记录IP地址
API调用支持：提供API，可通过代码调用和管理服务实例

open-webui

页面快照

功能特性

多模型适配：可配置任何符合OpenAI api规范的模型服务作为端点
RAG：支持本地上传及读取云端文档作为RAG对象
支持图片生成、网页搜索、网页浏览等agent功能
多用户管理：提供RBAC权限管理模块
pipeline功能：类似工作流，可加载或自行创建pipeline，通过代码执行器进行执行并获取结果
移动端适配

lobeChat

页面快照

功能特性

多种模型服务商支持：支持包括OpenAI、Google在内的海外模型服务商（通义千问、minimax、智谱AI、KIMI在内的国内模型服务商也终于不用共用一个OpenAI api配置入口了）
语音输入输出
图片上传及生成
插件：支持自定义function或从插件商店下载插件进行安装
配置导入导出：支持导入及导出assistant配置

Khoj

页面快照

功能特性

多端适配：除web和h5端，还提供Emacs、Obsidian插件和WhatsApp支持
多种文档类型支持
agent支持：可加载或自定义agent
快捷指令：对话中可指定知识库检索、网页检索、网页抓取等agent行为
自动化任务：可自定义自动化任务，用于在对话中唤起或供agent调用
语音输入输出

对比

基于项目的功能特性，整理它们的适宜对象和适宜场景

名称	适宜对象	适宜场景	原因
LibreChat	个人	轻RAG使用，无搜索及其他agent能力需求	界面简约，想要使用一个类chatGPT的界面可用，但对function calling等Agent场景支持不足
anythingLLM	个人	轻RAG，个人Agent探索	基础配置丰富且简单，基本可以做到开箱即用；log记录完整，可观测性是这些项目中最高的；长期记忆作为个人Agent必备模块，值得期待
open-webUI	学校、组织等团体内部使用	轻RAG，多种模型对比切换，复杂工作流共享	较为完善的权限管理模块，pipeline、RAG、同时请求多个模型、playground等功能模块相比于其他几个项目，在做模型对比及Agent探索方面能提供更多的支持
lobeChat	Agent设计社群	搭建Agent共建共享社群	以Agent设计（prompt+plugin）作为核心，连对话界面都是以assistant划分，再以对话session为区分。如果更想要探索和分享Agent设计，而非致力于为用户提供开箱即用的对话服务，可以选择。
Khoj	个人（尤其是文字工作者，研究人员，独立开发者）	知识积累，文字编辑辅助，个人知识检索	除web和h5之外，提供Emacs、Obsidian和WhatsApp嵌入支持，原生可连接notion、github repo、本地文档，这样的设计基本可以理解为随时随地检索私有知识库（连接你的第二大脑）。交互可爱，但整体有很多细节待打磨。

延伸讨论

在倒腾和对比这些项目的时候，我的关注点，逐渐从UI设计、系统功能，转移到了设计理念，并不断地冒出“为什么需要LUI”，“为什么我需要另外多一个对话页面来做这些事”以及“在不同的场景下，我们最舒服的使用AI的方式什么？”等等类似的问题。

至今仍然感叹chatGPT的产品设计，一个简约可爱的对话页面，提出一个问题，就一定能获得回答。这样的交互逻辑，掩盖了LLM复杂又强大的事实，仅给人获得即时响应、即时满足的快感。发布两年之后，几乎所有的LLM-based产品都有对话页面，这是真正的产品设计革新。
那么，这样以对话为核心页面的形态，是文本这单一模态下，最优的解法了吗？如果去看微软、字节、月之暗面的产品矩阵和优化方向，最直观的感受是两个字：融合。做客户端，客户端内集成浏览器、自家其他AI应用，做插件，以浏览器插件的形式无限接近用户的日常工作流，做系统，以多模态和硬件能力，从系统层面实现完整的体验。

AI产品的价值核心应该是“连接、汇总、探索和高效执行”：能够连接多种资源；能对资源内容进行有效汇总；能够基于场景需要进行一定探索和延伸以及能够依据指令进行任务执行。这或许是为什么经过chatbot之后，行业内开始卷Agent了。人们在期待更高的效率，即使这背后的代价是同时交出对过程的控制权。负责任的AI产品，应该要替用户对过程进行控制，and that’s the tricky part.
基于这四个方面，如果讨论对话类产品的最完善形态，功能方面我会想到以下几点：

检索：无论存储位置、文件类型，都应该可以被检索，并且用来生成回答
环境感知：除了当前对话页面由用户所输出的内容，能够对当前用户所处的时空环境和进行的事务有一定感知
记忆管理：之前在写其他post的时候有讨论过Agent的记忆对于整体的体验的重要性，简而言之，你之于我是你是因为我们之间有共同的记忆，而不是你多有本事或者脑子有多聪明。一个能够自动提取对话实体，拥有长期和短期记忆，并且会自我优化的记忆系统。
工具使用：不需要太多，但需要能够与当前用户所使用的设备本身的功能有一定的交互，例如设闹钟、建日程、写邮件等等

产品形态方面我更倾向以下几种：

浏览器插件：做浏览器插件的价值点在于，我们日常工作使用的很多软件都是BS架构的，接入浏览器，很大程度上缩短了使用路径，降低了使用时的心理成本
工具类产品的插件：如果有一定的基础积累，其实可以做专业工具软件的插件，和浏览器插件是一个逻辑，即无限接近用户的实际工作环境
桌面应用：能够感知系统状态，具有系统文件访问权限以及系统功能使用权限，网络搜索权限等基础权限，一个本地的、随时待命的、不用尴尬对机器说话的“Siri”

写了这么多之后，脑子里冒出来一句话，很适合作为总结：对话，不是产品形态，而只是一种交互方式。我们要关注的，始终应当是如何有效地获取并呈现信息以及如何尽可能缩短用户的操作路径。

介绍