一直对AI的产品形态很好奇。一方面是它带来的惊喜，在最初体验Perplexity.ai时，虽然前一两次搜索我并没有找到答案，但在这几次探索后，我逐渐发现原来是自己问错了问题，就像xy问题一样，AI帮我指出了那个原来我想问的x问题。然而，在传统的搜索引擎中，与此对标的功能「猜你想搜」，大部分时间只能解决错别字的问题，而并不能识别用户的真实意图，也就不能让用户得到想要的答案。另一方面则是对UI产生的悲观态度，如果像ChatGPT一样仅仅用一个对话框能够完成所有的事情，以后人机界面是否只会像Python REPL界面一样，以自然语言代替编程语言，完成所有的交互？
答案显然是否定的。最近听的两期Latent Space的podcast回答了我的大部分由此产生的疑问。Building the AI × UX Scenius - with Linus Lee of@Notion 关注如何更好的呈现现有的AI能力，请到了Linus Lee - Research Enginer, Notion AI，主要的分享涉及一些Notion AI的产品形态，包括「AI Autofills」「AI Block」以及背后的思考 。From RLHF to RLHB: The Case for Learning from Human Behavior - with Jeffrey Wang and Joe Reeve of Amplitude 则关注AI产品的数据分析工具，请来了Jefferey Wang与Joe Reeve@Amplitude，主要分享如何更精确地收集用户反馈用来做数据分析，或者帮助AI模型更好的迭代。两期着重强调了「用户引导」与「用户行为反馈」。
Building the AI × UX Scenius
先说说Linus Lee这期。与许多人设想地一样，Linus也着重强调了AI交互设计应该考虑到语言模型的局限性，应该将语言模型擅长的部分与正确的用户预期对齐。一个简单的例子是「聊天框」与「搜索框」：如果是一个像OpenAI一样的聊天框，用户可能会向聊天框里输入任何奇怪的问题，比如把对面当成人而在输入框里输入Hello，此时用户甚至对答案没有明确的预期，所以也不会「对齐预期」的发生。而搜索框在外观上区别于聊天框，更加直观地传递了它所代表的功能，让用户真正地把AI视作工具。同时，在搜索的语境下，因为有了更多的限制，比如在飞书中的「消息」搜索框智能够搜索到飞书的消息，让数据搜索的范围减小，也能让模型在更小的问题空间下更能准确地解决具体问题。
播客里主要有两个概念值得分享:
Mental Models (心智模型): 正如聊天框与搜索框会对用户理解界面产生影响，Linus在后面的分享中提到了UX中很重要也很经典的概念 - Mental models，并举了一个现在电脑上音量条的设计作为例子：现在音量调节的大小都是通过数字0-10或0-100来显示的，假设当用户现在从音量40调节到80，用户会理所应当地认为音量增加了一倍。但实际上对扬声器来说它的耗电量实际为原来的4倍，然而这并不重要，重要的是用户如何理解眼前的UI以及它所采取的行动是否符合他所预期的效果。此时，consistent mental models - 对眼前的UI有统一的建模就显得尤为重要，它定义了用户如何理解眼前的界面。
Constraints and Flexibility (语言模型的局限与灵活性): 除了调整用户预期，Notion AI在设计时也考虑了语言模型的局限性。正如前面所说，在小范围更问题空间内发问可以让语言模型更精确也更能发挥它的长处。这个概念在Notion里，就可以浓缩成一些确定性的高频使用场景，比如「总结」比如「会议纪要」。在Notion Project的设计中，「总结」是一个在其右键的context menu上的一个确定的按钮。另外也可以看到在菜单上除了「Summary」，Notion AI保留了「Custom autofill」兼顾了高级用户的创造性探索。
嘉宾Linus在其他的公开分享中的框架或概念我认为更值得借鉴：
Point, Select & Action (充分表达的交互意图): 本期播客其实更像是为了新的Notion Projects与Notion AI做广告。实际上更加启发我的是嘉宾Linus在其日常blog里关于AI UX的分享。在 Generative Interfaces Beyond Chat 中，Linus提到了「Point, Select & Action」的概念，这个概念很容易在现有的交互中找到例子，比如此时用户希望复制一段文本，Ta可能需要将光标移动到一段文字的开头，按住并拖动光标选中高亮一部分的文本，再进行右键复制的操作。在这个例子里，光标的起始位置就是「Point」，而拖动光标则代表「Select」，用户由此来表达自己将要对这部分文本采取复制的「Action」。通过以上三点系统可以完全理解用户的交互意图，给到用户正确的响应预期。实际上，上图的context menu就是「Action」的具体例子，其代表了在确定范围内，即某个table column作为「Point」和「Select」，提供给用户所能采取的所有可能的「Action」。这里我特别喜欢原文的表述：
Funnel the users to the right action
funnel这个词我认为用得比narrow还要形象。
Feedback Loops: Linus也提到了user feedback loops的重要性。就像最初遇到ChatGPT我不知道该问什么问题而懵在那里一样，在多数情况下，用户更倾向于「选择」而不是「创造」。因此，在结果比较好衡量的情况下，可以尽量返回给用户更多的结果让用户来选择自己喜欢的那个。例如在Midjourney生成多张图片，或者对文章总结生成多个答案都属于此范畴。这样的设计在下面的一期播客也会提到，不止可以让用户更满意AI输出的结果，还能够根据用户行为（选择哪个答案）来评价模型输出的答案，以此来增强模型效果。为了提供完整的Feedback loops，与此期播客相关的AIxUX NYC延伸出来另一个设计方向或者说理念 - 「Prompt space exploration」，通过保存本次与Generative AI对话session的所有路径，用户可以看到自己从最初的prompt通过何种路径一步一步修改到最终的成品的。与此相关的设计在 AI X UX NYC 有不少的展示，比如：
From RLHF to RLHB: The Case for Learning from Human Behavior
Amplitude则先分享了自己的创业故事。Amplitude这家公司最初的名字为SonaLite，是一个主要解决语音转换文字问题的公司。它的设想是人们在开车或者类似不方便使用手机的时候，可以通过此种交互方式流畅地在手机上使用IM功能。随着时间推移，两个创始人Spencer和Curtis很快发现实现这个产品最困难的技术在于语音识别，但两个人都不是机器学习背景出身，对花精力解决此类问题并不是很感兴趣，相反地，他们开始思考类似「用户为什么喜欢他们的产品？」的问题，并以此构建了一系列分析工具来帮助他们理解用户行为。结果，与他们同一批在YC孵化的公司在看见他们使用的分析工具后，对此产生了浓厚的兴趣。同时他们发现市场上并没有与他们现有产品类似的工具，他们就此转型，变成了一家现在专攻于toB的数据分析工具公司。他们的目标，就是挖掘更多的用户行为信息，并以此来帮助客户实现商业化得最大成功。
以下三点对我很有启发：
Thinking Path (思考路径): Joe的回答，从「我们希望将AI能力加入到我们的产品中」这个假设开始，做出了一系列的猜想。
Evalution (结果评估): 此外，和Linus一样，Amplitude也提到了关于用户反馈的问题。作为以收集用户行为为根基产生商业洞察的公司，缺少用户行为的捕捉可能是一个毁灭性的打击。如果交互设计真的沦为了在文本框之中用户与AI的对话，那将无任何商业洞察可言。回想起让用户给语言模型生成的答案like/dislike的反馈，他们对此表示悲观，并没有许多用户会真的点击并发送反馈。而零反馈的结果会让整个系统无法衡量自己的输出。他们给到的解决方案与dreamwalker很类似，通过一系列用户的选择输出结果的行为来代表用户对AI系统的真实评价。这里引用他们的原话来做总结:
Every AI application should figure out how to learn from all their real users
Measure (衡量AI对产品的价值): 主持人@Swyx提了一个非常有价值的问题：作为数据分析工具的公司，在AI era可以给到一些公司什么样的建议？比如应该去关注什么样的Analytics的结果？Jeffery的回答也干脆直接：北极星指标。他表示很多公司盲目地把AI加入自己的产品中，却不知道所加入的AI能力对自己的公司收益是否真的相关。比如任何一个有「界面」的公司理论上都可以推出一个chatbox (backing up with GPT) 在他们的界面中声称自己支持了AI能力。但这很有可能对公司收益没有任何帮助。所以在加入AI能力之前，一定要想清楚AI是如何与自己的北极星指标相关的。（相比之下我觉得Notion在今年3月左右就宣布了自己的AI战略 - Adding AI LEGO block into Notion，对比Amplitude的动作要坚决许多）
作为工程师，我总认为AI系统下的系统架构会与传统的后端系统相差许多。如果GPT的愿景是属于每个人的助手，那么他对系统的延迟敏感程度就再也不会是系统设计的首要重点。因为我对个人助手的期待是：只要结果够好，1min或10min并没有巨大的差别。
最后还想说说这个Notion AI的工程师Linus，嘉宾Linus Lee称得上是一个高产的builder，在他的blog中有超过100多个自己的side project。其中包括一门叫做Ink的编程语言、基于Ink实现的个人搜索引擎Monocle、以及甚至在Spotify上发行的两张音乐专辑等等，涉猎十分广泛。他在节目中也分享了自己做side project的习惯：对于每一个side project只选一小部分自己并不熟悉的部分，比如一个project只学习GPT API，另一个project只学习Next.js，这样设置milestone的方式可以很好地看见自己的进步也更容易建立自信。另一方面，如果有很多不熟悉的模块交织在一起，对于个人其问题的复杂度就会显著增加。「one thing at a time」可以帮助他让学习他的曲线显著降低。
关于「one thing at a time」这点，我想到了John Carmack之前也分享过，他认为如果自己当时先做好Doom的网络联机版本，再去开发Quake会让Quake的开发进程更加顺利。（对于一个多人联机的网络游戏Quake需要在多端上同步各个玩家的状态/行动/输入，而同时Quake这样的FPS游戏天生对帧率有极高的要求，这就让每一帧所需要同步的多端状态/行动/输入变得更加困难。「多人联机」与「3D实时渲染」两大模块之间的交互曾经让Carmack头痛不已。）
", "url": "https://milanow.github.io/2023/07/02/ai-x-ui-beyond-chatbox", "date_published": "2023-07-02T00:00:00+00:00", "date_modified": "2023-07-02T00:00:00+00:00", "author": { "name": "milanow", "url": null, "avatar": null } }, { "id": "https://milanow.github.io/2023/06/14/langchain-retrieval-webinar", "title": "LangChain Retrieval Webinar", "summary": null, "content_text": "LangChain Retrieval Webinar分享还是一期LangChain的webinar: https://www.youtube.com/watch?v=VrL7AbrY438, 本期的标题为「LangChain Retrieval Webinar」，主要请到了两位分享人分享他们在knowledge-intensive的IR task下的一些最佳实践: 一位是Vespa.ai的搜索工程师Jo Kristian Bergum，分享了他在Vespa所做的使用google/flan-t5-xxl · Hugging Face来生成合成queries，补充标注ranking model数据的pipeline。主要是用几个精确的prompt examples来帮助生成q-d的正负例。核心模块我理解有两个，一个是synthetic query generator用来生成q-d，再用consistent check检查看生成的doc在现有搜索服务里是不是被排在第1位（如果不是第一位则丢弃这个q-d），接着根据留下的q-d再生成2个负例，最后喂给模型。同时也在GitHub - vespa-cloud/cord-19-search: Vespa application making an index of the CORD-19 dataset.的例子中简单验证了此种方法以low cost迁移domain的可行性。更详细的介绍可以在Improving Search Ranking with Few-Shot Prompting of LLMs | Vespa Blog中找到。另一位是Colbert的作者Omar Khattab, 在简单回顾了下ColBert的发展后，他也将重点转移到了如何提高domain shift时的检索效果上，毕竟zero-shot能力有限。他在[2212.14024] Demonstrate-Search-Predict: Composing retrieval and language models for knowledge-intensive NLP (arxiv.org)提出了Demonstrate-Search-Predict编程模式，把DSP作为LangChain中的「Tool」的tool-builder，以此来告诉LangChain agent如何更好地使用Colbert（而不是zero-shot）。作为一个tool-builder，我理解的DSP实际上是一个python function, 是step-by-step的根据使用场景更精细化地封装LM与RM。在dsp/intro.ipynb at main · stanfordnlp/dsp · GitHub的第4和5个例子里，可以看到如何用DSP的模板来构建multi-hop QA的检索过程。他把结果都写进cache里了，所以不需要更OpenAI key也可以在notebook中跑原文的结果。", "content_html": "分享还是一期LangChain的webinar: https://www.youtube.com/watch?v=VrL7AbrY438, 本期的标题为「LangChain Retrieval Webinar」，主要请到了两位分享人分享他们在knowledge-intensive的IR task下的一些最佳实践:
一位是Vespa.ai的搜索工程师Jo Kristian Bergum，分享了他在Vespa所做的使用google/flan-t5-xxl · Hugging Face来生成合成queries，补充标注ranking model数据的pipeline。主要是用几个精确的prompt examples来帮助生成q-d的正负例。核心模块我理解有两个，一个是synthetic query generator用来生成q-d，再用consistent check检查看生成的doc在现有搜索服务里是不是被排在第1位（如果不是第一位则丢弃这个q-d），接着根据留下的q-d再生成2个负例，最后喂给模型。同时也在GitHub - vespa-cloud/cord-19-search: Vespa application making an index of the CORD-19 dataset.的例子中简单验证了此种方法以low cost迁移domain的可行性。更详细的介绍可以在Improving Search Ranking with Few-Shot Prompting of LLMs | Vespa Blog中找到。
另一位是Colbert的作者Omar Khattab, 在简单回顾了下ColBert的发展后，他也将重点转移到了如何提高domain shift时的检索效果上，毕竟zero-shot能力有限。他在[2212.14024] Demonstrate-Search-Predict: Composing retrieval and language models for knowledge-intensive NLP (arxiv.org)提出了Demonstrate-Search-Predict编程模式，把DSP作为LangChain中的「Tool」的tool-builder，以此来告诉LangChain agent如何更好地使用Colbert（而不是zero-shot）。作为一个tool-builder，我理解的DSP实际上是一个python function, 是step-by-step的根据使用场景更精细化地封装LM与RM。在dsp/intro.ipynb at main · stanfordnlp/dsp · GitHub的第4和5个例子里，可以看到如何用DSP的模板来构建multi-hop QA的检索过程。他把结果都写进cache里了，所以不需要更OpenAI key也可以在notebook中跑原文的结果。
昨天有一个webinar，请来了LangChain (Harrison Chase)、BabyAGI（Yohei）还有ReAct的作者（Shunyu Yao），这里有回放：
视频地址：https://www.youtube.com/watch?v=L_Guz73e6fw
内容介绍：最近有一个特别火的视频（实际上是一期播客），虽然里面没有提到任何与技术本身相关的事情（因为Sam的口风太紧了），但很值得一看。Lex Fridman与Sam Altman谈论的话题很广，不过大部分还是关于现有GPT-4与AGI实现路径的讨论，尤其是安全方面里面有一些内容我觉得挺有趣：
注1：Lex Fridman其实早些时候采访过许多OpenAI其他的人，与Ilya对谈的时候是2020年，那个时候还只有GPT-2：
注2：某科技自媒体对此视频解读的标题为：「AI可能会杀死人类」
", "url": "https://milanow.github.io/2023/03/29/lex-fridman-interview-with-sam-altman", "date_published": "2023-03-29T00:00:00+00:00", "date_modified": "2023-03-29T00:00:00+00:00", "author": { "name": "milanow", "url": null, "avatar": null } }, { "id": "https://milanow.github.io/2023/03/24/reinforcement-learning-from-human-feedback", "title": "Reinforcement Learning from Human Feedback", "summary": null, "content_text": "Reinforcement Learning from Human Feedback视频地址：https://www.youtube.com/watch?v=2MBJOuVq380&t=1s内容简介：虽然听GPT有点听得PTSD，但为了看RLHF还是要结合它来看。一些前置的RL概念可以看这篇：https://paperexplained.cn/articles/article/detail/33/#id-h2-e37ba622acc1这个视频主要讲了三件事儿： RLHF的起源，从decision making开始： 08年基于TAMER framework，也就是人类直接给agent reward来应用到俄罗斯方块的AI (icdl08-knox.pdf (utexas.edu)) 17年的时候将人对于特定agent移动任务的trajectory偏好训练了一个reward predictor得到了很好的效果 (https://arxiv.org/pdf/1706.03741.pdf) 20年的时候OpenAI尝试将human feedback应用于文本summarize (这篇就是之前@Zhenyu Duan 说KL距离公式写错了的那篇paper) (https://arxiv.org/pdf/2009.01325.pdf) LLM与RLHF结合的方式（主要是基于InstructGPT的概括：https://arxiv.org/pdf/2203.02155.pdf） pre-trained supervised model + reward model + fine tuning with RL 对比了Anthropic/OpenAI/DeepMind在apply RL on LM方法上的异同视频下面给出了其他RLHF在LM上面的探索： Fine-Tuning Language Models from Human Preferences (Zieglar et al. 2019): An early paper that studies the impact of reward learning on four specific tasks. Learning to summarize with human feedback (Stiennon et al., 2020): RLHF applied to the task of summarizing text. Also, Recursively Summarizing Books with Human Feedback (OpenAI Alignment Team 2021), follow on work summarizing books. WebGPT: Browser-assisted question-answering with human feedback (OpenAI, 2021): Using RLHF to train an agent to navigate the web. GopherCite: Teaching language models to support answers with verified quotes (Menick et al. 2022): Train a LM with RLHF to return answers with specific citations. Sparrow: Improving alignment of dialogue agents via targeted human judgements (Glaese et al. 2022): Fine-tuning a dialogue agent with RLHF ChatGPT: Optimizing Language Models for Dialogue (OpenAI 2022): Training a LM with RLHF for suitable use as an all-purpose chat bot. Scaling Laws for Reward Model Overoptimization (Gao et al. 2022): studies the scaling properties of the learned preference model in RLHF. Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback (Anthropic, 2022): A detailed documentation of training a LM assistant with RLHF. Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviors, and Lessons Learned (Ganguli et al. 2022): A detailed documentation of efforts to “discover, measure, and attempt to reduce [language models] potentially harmful outputs.” Dynamic Planning in Open-Ended Dialogue using Reinforcement Learning (Cohen at al. 2022): Using RL to enhance the conversational skill of an open-ended dialogue agent. Is Reinforcement Learning (Not) for Natural Language Processing?: Benchmarks, Baselines, and Building Blocks for Natural Language Policy Optimization (Ramamurthy and Ammanabrolu et al. 2022): Discusses the design space of open-source tools in RLHF and proposes a new algorithm NLPO (Natural Language Policy Optimization) as an alternative to PPO.", "content_html": "视频地址：https://www.youtube.com/watch?v=2MBJOuVq380&t=1s
内容简介：虽然听GPT有点听得PTSD，但为了看RLHF还是要结合它来看。一些前置的RL概念可以看这篇：https://paperexplained.cn/articles/article/detail/33/#id-h2-e37ba622acc1
这个视频主要讲了三件事儿：
视频下面给出了其他RLHF在LM上面的探索：
视频地址：https://www.youtube.com/watch?v=kCc8FmEb1nY
内容简介：这期主要关注Andrej实现「Self-attention」「Multihead self-attention」的过程，他以莎士比亚的剧本为训练数据写出了更多的仿莎士比亚剧本，比如：
The top in a world by susphoring grace. LUCIO: We muse hath resistes him so sovere: son’t his other wrough stands of coverent sh’d: he has here, and stand it and poor exceeder or a Henry’s last, stay not in faith, forewell’s base of graves, thanks, happy comparel, warmentfully: may as face by the courst, that strangth errise hath breathed. Hastings come to Valenting. HERMIONE: Well have been bolly poor late Is the lords.
视频的最后比对了他自己在两小时实现的tiny GPT与ChatGPT的区别（然而似乎他并不打算继续介绍fine-tune和PPO的部分，也许和他入职OpenAI有关）。视频里面的一些资料（原Youtube视频介绍中有提到）：
Supplementary links:
从这个post开始学习模型构建的基本模块与概念，Andrej Karpathy是一个非常好的老师
视频地址：https://www.youtube.com/watch?v=VMj-3S1tku0内容简介：从计算最简单的导数开始，建立了一个3层网络，按照Pytorch的API的形式建立了神经网络数据结构，用Python手动模拟了正向传播、反向传播等计算过程。视频里面的一些资料（原Youtube视频介绍中有提到）：