没做过 AI app 的：AGI 要来了，AI 无敌了 做过 AI app：难说 难说
目前现状是，对于简单任务，zero-shot，即只通过描述任务就可以让 AI 完成任务的效果真的很惊艳 但对于复杂任务，就需要设计复杂的 pipeline，去解决 AI 的幻想、不确定性。现在遇到问题最佳的解决方案依旧是加更多的 AI 进去，但就会造成一个 pipeline 要处理很久，用户可没那么多耐心
“There is a wall” 这个 wall 就是，如果基础模型不能持续提升，那就需要在 ai model 之上设计更多复杂的 pipeline 去做处理。但因为 llm 的不确定性，增加的 pipeline 可能是 *上雕花，并不能获得确定的提升，甚至可能在部分场景的反作用。 而，如果基础模型能持续提升，人类搞得复杂 pipeline 可能在基础模型升级后变得毫无意义。
当你真的开始用 AI 去做一个复杂任务，就会遇到跟不确定性搏斗的痛苦。
当然，这是站在旧时代程序员尊崇的确定性上得出的结论，可能下一个范式就是接纳不确定性，与不确定性共舞，或者在不确定性的基础上找到确定性。 就像单个分子的热运动是不规则的，但海量分子就会表现出规则的物理现象。
如何把 AI 的不确定性以确定的方式构建工程框架可能是一个有趣的方向
一个暴论 如果你用 react 性能工具去 debug chatGPT 等知名的网站，你会发现甚至会出现每输入一次内容就全屏重渲染的 bug
首先这确实证明 react 是真难写（确实），其次是，自己开发的时候真没必要特别纠结那些重渲染等问题，一次重渲染占不了多少 cpu 时间，也消耗的不是服务端性能。
先实现效果，而不是追求代码洁癖
前段时间跟 @i5ting 录播客的时候聊到，我觉得 LLM 下一步可能是：
- 通过复杂 flow 这种形式，在一个处理中，引入更多 LLM 节点来进行多次思考，引入传统 API 节点来进行外部信息的引入和辅助抑制 AI 幻想
前者，例如传统 RAG 就是拿用户的 query 获得文档再让 AI 回答。假设 token 越来越便宜，速度越来越快，我们可以做更多 LLM 节点进去 首先是 query ，我们先用一个 LLM 节点去重写 query 成多个 意思相近但表达不同的 query 形式，来解决人类表达的多义性问题。 对于查到的文档，我们可以用一个非常廉价但非常快的 LLM API，把原始 query 和 每个文档传入，让 LLM 评价这个文档和原始 query 的相关度，然后根据这个相关度给所有的文档排序，找到相关度最高的几个文档，再传入给最终的大模型进行回复。 （当然这样会比较费 token，在 token 还没那么廉价的时候，可以用 reRanker 达到类似效果） 也就是，建立在 token 速度和价格的新摩尔定律下，我们在一个请求中引入更多 LLM 来提升效果
后者，是在整个 flow 流程中引入更多的现实世界信息和真实世界 API 的验证。我问内部 agent，xxx 工作是哪些人做的，然后 LLM 在生成的时候有一个工具能够通过 API 查询到真实数据库中的答案，并根据这些答案来调整自己的思考 和流程。 也就是用真实世界的信息，或者 ground truth 去负反馈调节 agent，避免进入幻想和完全错误的路线
- 通过工程化来把 LLM 的不确定性给确定化。 所有新技术出来都是不确定的，例如磁盘存储 0/1 也是有概率错误的，但我们可以用纠错算法来解决这种不确定下，把技术变得稳定。 我们已经惊叹于 LLM 表现出来的各种能力，现在需要用工程化的思维，把这些能力中有价值的部分，通过各种工业化的工具稳定下来，可验证 可复现。 例如，prompt 是玄学，那我们可以给 prompt 设计 Ops 流程，每一个 prompt 会在几百条精选过的测试数据中运行，并给出对结果的打分（打分可以通过更高级的 LLM 或者 agent 进行），然后由此来判断我对 prompt 的修改是让结果变得更好了还是更差了。 这样，我们就能把 prompt 的“玄学”，变得可追溯 可测试，也就是更工业化
这段播客录在上周。这周 OpenAI 发布了 o1，我觉得 o1 其实就是第一个路线的产物。o1 的多层迭代思考其实之前的 reAct、CoT 都有类似的效果，而 o1 比较有趣的地方就是其自己能够进行负反馈，其可以自己判断现在是否走在正确的路线上，如果有问题则及时跳回上一步 o1 是在推理层新的 scaling law
而对于第二个路线，OpenAI 上次发布会强调了自己模型新的可复现性，也就是 “Reproducible outputs”，其可以通过参数设置让 LLM 的输出是文档可复现的，这样就能推动 LLM Ops 走向可复现和工程化
朋友要做 AI 的公开课，我去讲 Langchain.js 入门、RAG 和 Agent 的基础实现入门，代码写完了，ppt 也快差不多了
好不容易写一次，不想讲一次就放那了 如果有组织恰好需要这类型的分享，可以勾兑勾兑
这是相关代码:
一个有趣的提取文章中 tags 的流程
首先，将文章切割成 1000 字每块，200 字 overlap 的块，然后从中均匀采样 5 块
对每块使用 llm 去分析出 5 个可能的标签，且对每个标签与原文的相关度进行打分。prompt 中 强调 “这是一篇文章中的切片，你需要根据你的经验去推测适合整篇文章的标签”
然后，五块采样，一共会获得 25 个标签及打分。进行合并操作，如果两个标签完全相同，则得分取平均值。合并完后，取得分最高的前五个标签。
对原文进行均匀采样，且可以根据需求动态调整采样数，来节约 token 数 让 llm 打分，来量化的找到最合适的 tag 所有请求都是并发的，跟单次请求耗时一致
当然这个效果到底能比其他方式好多少，会之后通过实验来测试，并进行定量分析。 prompt 是有 “玄学” 部分，但我们可以量化的 LLM ops 来验证我们这些 “灵光一闪” 的 prompt tricks 是否有效
这个操作基于我之前的一个想法
我们正常的压缩是站在计算机和信息论的角度，也就是从数据角度来讨论 无损和有损压缩，整个过程中只处理数据，不存在类人的 认知和理解
但，随着模型的知识和理解能力的提高，我们是否可以从 认知角度去理解压缩这件事。例如跟模型说 “美国 全名” 就会获得 “美利坚合众国”，在这个过程中，是有模型的认识和理解参与进来，而不是单纯从数据角度
那进一步，人类语言中的冗余部分是很多的，信息密度并不高，我们可以假设其中 40% 的字符量输入给 AI，AI 就能理解原文 95% 的含义，这个理解过程是掺杂了 AI 对 “人类常识” 的预先了解。
在这个理解的基础上，用抽样提取标签只是非常小的一个 demo，是想尝试让 AI 去 “从文章切片去推测整篇文章可能的标签”，让 AI 去进行合理脑补，来用小的信息输入 + AI 预先掌握的常识，来获得更好的效果。 如果这个想法是对的，我觉得是会有更好玩的落地场景出来
