- Currently working on Microsoft
- An amateur magician
- A host of a tech podcast Web Worker
- I’m actively looking for collaboration on Qwerty Learner , let's make keyboard learning a blast together!! 🪄
- In my coding journey, I've been lucky enough to work at prestigious firms like HULU(Disney Streaming) , ByteDance , and Ke Holdings , where I gained a wealth of experience in my field.
- Always open for new opportunities and connecting with new friends.
前段时间跟 @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 预先掌握的常识，来获得更好的效果。 如果这个想法是对的，我觉得是会有更好玩的落地场景出来
我是那种会纠结最佳实践的人，即使是无关紧要的事，记得在巨硬实习的时候，需要用 win，我问 mentor “你们一把会把代码存在哪个目录” ，感觉 mentor 看我像傻子 hhh
因为 mac 选手一般是 /Users/<user_name>/Developer，mac 甚至会给这个文件夹自动改图标
而且我估计很多实习生会像我一样，很多傻傻的问题不好意思问，怕露怯 但有了 copilot 真的不一样了，你甚至可以问 “一般命名习惯” “帮我起个变量名” “一般放在哪个文件夹”，这种 约定俗成，但又不好查到文档和问前辈的问题
