Posts

Cursor, Windsurf 等 LLM 辅助编程工具得到了大量关注。另一方面，很多工作其实并不会非常多涉及编程，即使是有数据处理，也会使用 Excel、SPSS等工具。但是与编程不同，这些专门工具在 LLM 上是缺乏预训练支持的，我也体验过几款 Sheet Copilot 工具，发现距离真正可用还有比较大的差距。 比如飞书的 Sheet Agent，也就是他们多维表格的 AI 助手，几乎很难做到按照指令办事，更多时候只能处理简单的指令，比如求和、加粗等，如果要处理复杂指令，比如 统计 2010-2020年间销售量的分布，并对两款商品的销量进行 T 检验，创建一个新的工作表承载这个结果。 基本上是做不到的，然而其实后者才是大家真正需要的能力。要实现 Sheet Agent 有两个思路 生成代码去操作。比如使用 openxlsx 等。这种方法的好处是，可以借助 LLM 本身学到的代码能力，表示能力可能会更强。但坏处是，我们得专门为代码去设计沙盒，也很难对生成的代码进行性能优化。比如刚刚举的例子，「统计 2010-2020年间销售量的分布，并对两款商品的销量进行 T 检验」，这里使用 Python + openxlsx ，LLM 可能会更倾向于使用 Python 代码去计算分布、进行 T 检验，而非利用产品本身的能力。为了加速计算，各家文档产品都会做一些性能优化，比如算子的编排，使用 script（无论是 Python 还是 vbs）都有可能引起性能的大幅下降。 生成操作序列。对于文档产品来说，所有的操作都可以被刻画为 mutation，这里的 mutation 就是对表格的原子操作，所有的操作都能被还原为 mutation 的序列。好处是这真的像用户自己的操作，因此兼容原有的所有基建。但难点是：1. 不同的产品有不同的 mutation 设计，LLM 是无法 zero-shot 感知这些信息的；2. LLM 无法严格按照既定的格式输出 mutation 序列；3. 缺乏 mutation 层面的数据集，现有的数据集都是表格文件层面的 input 和 output。 现有的模型基本上都是使用第一种方法进行处理。在我看来当前的研究存在下列难题： 缺乏真实数据：当前的 benchmark 量都比较小，数据表也非常小，操作序列也很简单。这些都是脱离真实场景的，比如很多 Agent 是直接把整个数据表喂给了 LLM，这在真实场景上是不可能的。 缺乏有效的评估手段：和其他的生成任务一样，Sheet 操作任务也缺乏有效的评估手段，比如两个同样错误的操作，如何去评估哪个错得更多？两个同样正确的操作，如何去评估谁的实现更好？ 缺乏 mutation 层面的支持：正如上文所言，现实场景不可能涉及一个沙箱容器来执行特定的代码，一方面存在安全性问题，另一方面，这对于数据一致性、性能都是巨大的挑战。 SheetCopilot (NeurIPS 2023) × ...

随着cursor等代码助手工具的兴起，代码生成与检索成为了研究的热点。本文介绍ACL 2024的三篇文章，这三篇文章都非常有意思，关注在代码生成与检索的统一表示上。 [ReCo] Rewriting the Code: A Simple Framework for Large Language Model Augmented Semantic Code Search 首先介绍的是ReCo，这篇文章提出了一个非常非常简单但是有效的方法，用LLM去「翻译」代码，统一代码的风格，然后再去做检索。它想解决的问题，其实就是语义搜索这个问题，比如 Query: 实现UserDAO的函数 以往我们去用类似双塔结构，直接尝试对齐 Query 和 Code 的 embedding，但是这其实很难，因为代码的结构和自然语言的结构非常不一样。比如这里的 Ground Truth 是： class UserDAO { constructor(private db: Database) {} async findByEmail(email: string): Promise<User | null> { const result = await this.db.query(`SELECT * FROM users WHERE email = $1`, [email]); return result.rows[0] || null; } } 通过计算 Query 和 Code 的 embedding 的余弦相似度，$ \cos(q, c) $，来衡量 Query 和 Code 的相似度。之后，学者们提出了生成增强检索(Generative Augmented Retrieval, GAR)，通过 LLM 生成更加准确的 Query，然后再去做检索。比如我们可以让 LLM 先自己根据 Query 生成对应的代码，再去计算 生成的代码片段 和 代码库中的代码片段 的相似度。这样就避免了自然语言和代码之间天然的差异。 ...

什么是 Knowledge Tracing? Knowledge Tracing，中文知识追踪，可以理解为 IRT（Item Response Theory）在深度学习时代的新马甲。本质上，Knowledge Tracing（aka. KT）的目的是根据学生的历史做题记录评估他对不同知识点的掌握状态（在 KT 领域，这件事情被称为 Knowledge Estimation，知识估计）。 然而因为掌握状态其实是一个 Hidden State，我们并没有直接的监督信号能够给出学生对一个知识点的掌握是 10% 还是 30%，因此，目前的工作更多是在通过预测学生在没有见过的题目上的正确情况，去检验模型知识估计的准确性。 传统的 IRT 需要被深度学习方法所替代的原因有多方面。首先，传统的 IRT 主要依赖于对试题和学生能力的静态建模，通常假设题目难度和学生能力是固定的。然而，学生的学习过程是动态的，随着时间的推移，学生的能力会发生变化。IRT 的静态假设无法有效捕捉这种动态变化。此外，传统的 IRT 在处理复杂的题目特征和学生的多样化反应模式时显得力不从心。学生在学习过程中可能会遇到不同类型的题目，这些题目可能涉及多种知识点和技能，传统的 IRT 难以全面建模这些复杂关系。 深度学习方法能够更好地捕捉这些动态变化和复杂关系，从而提供更精确的知识估计。深度学习模型可以通过大量数据训练，自动学习到学生能力变化的模式和题目特征之间的复杂关系。 例如，在验证学生对「全等性」掌握程度的题目中， 题目 1（简单） 给定两个三角形 ABC 和 DEF，已知 AB = DE, AC = DF, ∠BAC = ∠EDF。请证明三角形 ABC 和 DEF 全等。 题目 2（困难） 在一个平行四边形 ABCD 中，E 和 F 分别是边 AD 和 BC 上的点，且 AE = BF。已知 ∠EAB = ∠FBA。请证明三角形 ABE 和三角形 CDF 全等。 如果只是简单地把题目和知识点进行关联，然后建立（知识点，对错）到掌握情况的映射，会失去对难度的建模。能完成题目 1 和能完成题目 2 对全等的掌握情况是不同的。传统的 IRT 难以捕捉这种细微的差异，而深度学习方法则可以通过复杂的模型结构来更好地建模这些差异。其实，除开难度，学生的完成情况，比如完全不会做和能完成一部分步骤也是有很大差异的，对完成情况进行考虑，我们称之为 Open-ended Knowledge Tracing。但这样的数据集比较难获取，目前大部分的工作还是在只包含选择题的数据集上做。 ...

这或许是我第很多很多次写「Hello World」，自己总是有一些表达欲，想要写成文字。同时也很羡慕一些朋友，有一个长期维护的 Blog 有很多质量优秀的文章。比如 Geelaw (虽然 GeeLaw 也已经三年没更新过 blog 了，读博的生活节奏太快)。我也尝试过很多次去做自己的 Blog，但是总是无疾而终，写一两篇文章，然后就搁置下来。 或许是某种「文字羞耻感」所致，也就是当自己回过头看自己写过的文章，会觉得哪儿哪儿都不好，干脆一删了之并且短期内不再继续输出。我说不准这是为什么，可能是自己太过于熟悉自己落笔的方式？或许自己的文字功底的确就是一般。 另一方面是，写文章是一件比较累的事情。无论是技术还是生活，有一个主题，展开成一个故事，而不是流水线式、裹脚布式去写，很需要精心布置。如技术类文章，很多人会写成使用手册，即使是一些偏概念的，比如介绍 Dependency Injection 的文章，很多人都会是：概念介绍 -> 业界现状 -> Toy 实现 -> 总结，这样去写。这样写没错，但是显得平淡。我想讲其实清楚技术的背景是非常重要的，这也是我从读论文和写论文这件事学到的。在 review 被人论文和被别人 review 自己论文的时候就会发现，introduction is all you need。 如何把一件事情的来龙去脉讲清楚，是非常重要的，也是很难的。 但是我还是想写博客。推特/微博并不是一个可以沉淀的内容平台，我还是需要博客去承载一些东西。并且也给自己定了一些 milestone，比如每个月至少产出一篇 blog👋。 也要求自己不能「从弱如流」，去产出一些问一下 ChatGPT 就能知道的内容。 这些内容关于技术，或是生活。

这是我在本科论文里的致谢，在此分享。部分人名做脱敏处理。 窗外柳绿花红，莺飞燕舞，好一番初夏之景。 二零一七年，我第一次踏上江汉大学这片热土，就被三角湖畔的习习凉风与阵阵蛙鸣吸引。“山不在高，有仙则灵；水不在深，有龙则灵”。山清水秀、藏龙卧虎的江大，似母亲般抚慰了我迷惘和躁动的内心，给了我丰厚的知识，塑造了我坚毅的品格。在即将离开江大的特殊日子里，这里的老师、同学、甚至一草一木都让我难以忘怀。 晓来风，夜来雨，晚来烟，是他酿就春色，又断送流年。 回望本科四年，我感慨万千。在前进的路上，引之以琼浆之人不胜枚举，而说到感谢，我竟一时语塞。首先，感谢我的毕业论文指导老师—🥳老师，感谢您悉心指导我毕业论文的构思、实验与写作。其次，我要感谢自动化系的🥰老师，在我本科的第一节课，是您为我打开了信息科学领域的宏伟蓝图，让我第一次从如此宏观的角度思考自己的发展方向，在我转至计算机系后，您仍对我万般关心，百种呵护。最后，我还要感谢与我亦师亦友的🤪老师，您让我感受到了情谊的真挚，也让我感受到了数学与计算机之间的奇妙魅力。 心有高朋身自富，君有奇才我不贫。感谢在大学四年里一直陪伴我的朋友们，你们或在生活上关心照顾我，或在学业上与我并头齐进，或在人生发展上为我提供不同的参考系。有友如此，便是我四年里最大的幸运。萍水相逢，青春作伴，此次一别，愿诸君珍重。 我还要特别感谢电影《无问西东》中的一段对白。 梅：人把自己置身于忙碌当中，有一种麻木的踏实，但丧失了真实，你的青春也不过只有这些日子。 吴：什么是真实？ 梅：你看到什么，听到什么，做什么，和谁在一起，有一种，从心灵深处，满溢出来的不懊悔，也不羞耻的平和与喜悦。 在我迷惘未来去向何方或是怀疑自己所经之路之时，我总会想起梅贻琦先生的教诲。 大学四年的生活如白马过隙，但我对计算机科学与技术的热忱却永不会衰减。大江歌罢掉头东，邃密群科济世穷。面壁十年图破壁，难酬蹈海亦英雄。