
仓库: https://github.com/ray-d-song/guesslang-js
效果展示: https://ray-d-song.github.io/guesslang-js/
最近我正在完成一个叫 EchoRSS 的阅读器项目,有一个我非常想要的功能,就是拦截订阅中的外链跳转(阅读全文、引用啥的),直接在当前页内显示。
有一个问题是返回的 HTML 代码块失去了语言标注(或者原先在 pre 和 code 标签上就没有标注语言),这样没法用 shiki 或者 prism.js 之类的工具进行代码高亮。
我找到了三个检测代码语言的方案:
这是一个部署在服务器上的 Ruby 项目,Github 用它来检测仓库的语言构成,如果你需要极高的准确度且可以在服务端运算的话,这是最优解。
highlight.js 是一个非常知名的网页代码高亮库,也是唯一一个提供自动代码检测的高亮库。
原理很简单,就是枚举语言的关键词,用这些关键词去一个个匹配文本,最后看哪个的匹配度最高。
hljs 有四个问题。
guesslang 是一个基于 tensorflow.js 的机器学习项目。
Microsoft 在 2021 年用 tensorflow.js 将这个项目移植到 node.js 上,为 vscode 增加了自动语言检测的功能。
一个越南小哥hieplpvip三年前又将这个项目移植到了浏览器上,不过也有三个问题:
而且这位小哥已经不再维护这个项目,3 月份有个支持 esm 的 feat request 一直没有回复。
所以我提取了 hljs 中的检测模块,又 fork guesslang-js 修复了上面那些问题,对比了一下两种方案,最终 guesslang 胜出,产物就是这个: https://github.com/ray-d-song/guesslang-js
貌似叨太多了,也许未来会有人需要这个,所以 po 一下。
如果有人了解 tensorflow.js 的话,希望可以推荐一些学习材料,我想进一步改为 web gpu 计算来提升效率。
1 musi 2024-11-22 08:45:45 +08:00 直接拿一个小语言模型判断就好了,感觉 1b 的就够了 |
2 songray OP @musi 不行,一是很难跑在浏览器里(大多数语言模型都是 pytorch 而不是 tf ),还有就是 1b 的模型不可能支持结构化输出,返回内容不稳定 |
4 songray OP @musi 我只能说这是我花时间摸索出来的结论,真的可行的话你可以贴个 showcase 链接给我… xxx 可行这种话没啥意义。 |
5 musi 2024-11-22 08:55:51 +08:00 @songray #4 看的出来你是真不想花时间搜索 直接 google "run LLM in browser"直接就出来了 https://github.com/mlc-ai/web-llm 你是真想别人把饭喂你嘴里才吃 |
6 ukhack 2024-11-22 08:59:51 +08:00 前端取一段丢给后端,后端接个免费的大模型就行了,比如说智谱 flash 。 打完收工 |
7 songray OP @musi 这就是我说的你压根没有花时间摸索就得出结论。 我就算用 0.5b 的模型也要下几百兆到浏览器里... 然后每次再推理十几秒,这有啥用? |
8 musi 2024-11-22 09:03:56 +08:00 @songray #7 那你应该用下载模型耗时太长反驳我,而不是“很难跑在浏览器里”,你不说清楚我怎么知道你对时间敏不敏感,万一你对对一次的下载时间不敏感后面加上缓存了呢? 感觉你沟通能力也不行 |
10 songray OP 这交流环境也太恶劣了... |
11 musi 2024-11-22 09:07:10 +08:00 @songray 你 po 的内容有说明你的产品运行在什么样的网络环境和设备环境吗?只能知道是跑在 web 浏览器上的,web-llm 是不能跑在浏览器上吗? |
12 musi 2024-11-22 09:07:58 +08:00 笑死,自己没说清楚别人给你找了解决方案还说交流环境恶劣。。。 |
13 vvhy 2024-11-22 09:09:23 +08:00 可以拿 polyglot 测试一下,哈哈 |
14 songray OP @ukhack 确实可以,实际上我也试了 cloudflare ai ,就是大模型返回实在是太慢了… |
16 LinYa 2024-11-22 09:13:31 +08:00 我觉得这个挺好的,有时候把网页扒下来转换成 md ,会丢失对代码块语言的标记,导致我得手动添加。 |
17 vvhy 2024-11-22 09:13:55 +08:00 @songray 不是方案,是可以解释为多种语言的代码 https://en.wikipedia.org/wiki/Polyglot_(computing) |
18 skallz 2024-11-22 09:35:24 +08:00 @songray 大部分模型是可以转化到 onnx ,onnx 在浏览器运行也有成熟的 wasm 方案,好处是各环境能保持一致,比 tf 好处理,不过 onnx 的 wasm 版本目前社区只支持 cpu |
19 june4 2024-11-22 09:50:32 +08:00 感觉代码高亮这功能不是那么有必要上这么重量级的东西在浏览器里,本地应用的话还行。 如果是我,我可能会搞个粗糙的高亮方案,集合 top 10 种语言的大部分重要关键字,和字符串/数字/注释格式,这几样东西才是最需要高亮的东西,搞个通用又朴素的高亮应付所有代码。毕竟高亮文本只是个辅助视觉提示,不需要那么精确和花骚。这套轻量方案几 K 代码就搞定了,而上模型又慢又要 M 级内存打底。 |
20 dhb233 2024-11-22 10:04:21 +08:00 说的是编程语言吧,感觉随便写写就能区分主流的语言,哪用大模型 |
21 zhmouV2 2024-11-22 10:10:26 +08:00 拿 llm 当解决手段疑似有点幽默了,属实是大炮打蚊子,感觉是不是对 1b 参数量模型有啥误解? stable diffusion v1.5 的参数量差不多也就这个数。如果这也算解决方案,我找 1000 个印度外包去人工识别好不好。。。 正经方法不外乎提取关键字做匹配或者依赖一个小的文本分类模型做检测,或者二者结合。就跟二维码定位差不多,要么依赖 cv 传统算法提取线段/点/矩形,要么搞个小的 mobilenet 去做 detection 。 |
22 ResidualSoils 2024-11-22 10:16:13 +08:00 我觉得楼主的分享很不错 |
23 songray OP @zhmouV2 是的,我觉得现在很多人形成路径依赖了... 一言不合大模型。 大多数任务依赖传统 cv 就可以了,大模型的速度和大小在很多场景下都是不可接受的。 |
25 june4 2024-11-22 10:33:03 +08:00 @songray 确实 200K 的话也不算太过份,你做的是 rss reader 吧,很可能整个 reader 的前端代码 zip 后也没有 200K ,这个小功能就超过整个 app 了。 |
26 yggd 2024-11-22 10:38:54 +08:00 magika 怎么样,模型大小也是 1M 左右,主要就是检测文件类型的 |
29 hafuhafu 2024-11-22 11:26:13 +08:00 长见识了,原来 VSC 的自动语言模式是用机器学习实现的,怪不得偶尔结果是错的 |
30 Alliot 2024-11-22 11:31:51 +08:00 百度有语言检测 API 参考 openai-translator |
32 Ocean810975 2024-11-22 15:37:17 +08:00 好文,mark 了,要是用大模型的人少说两句就更好了…… |
33 zoharSoul 2024-11-22 16:11:14 +08:00 用大模型也太幽默了 |
34 liuzhaowei55 2024-11-22 16:22:37 +08:00 via Android 不错,最近关注 Monaco editor ,也很需要语言自动判断 |
35 NoOneNoBody 2024-11-22 16:26:58 +08:00 |
36 ooTwToo 2024-11-22 16:40:39 +08:00 magika |
37 lllllliu 2024-11-22 16:44:57 +08:00 (随便说的)本质上是一个分类问题,用传统机器学习也是可以做的应该~ 各个语言的特征应该是都比较明显的,最好理解的算法应该是决策树了~ |
39 Plumbiu 2024-11-22 17:27:12 +08:00 代码高亮的成本太高了,就算有一些小模型,shiki 或者 prism.js 的体积都已经很大了,建议不搞 |
41 mahaoqu 2024-11-22 17:43:52 +08:00 Java 字符串里写 SQL 的能匹配上两种语言,还是只有其中一种? |
42 mightybruce 2024-11-22 17:52:46 +08:00 觉得用大模型来检测,似乎是一种费力不讨好的方案。 毕竟一个语言要高亮的话也就那么一些关键字和语法,你做好匹配不就行了。 我用的很多专业的代码编辑器也就是这么做的而已。 |
43 luckykelan 2024-11-23 19:33:28 +08:00 @musi 社区氛围就是你这种大聪明多了搞坏的,人楼主正常分享,你跟个二皮似的又说人家不需要结构化输入了,又说人家不应该这么反驳了,你特么咋这么有爹味呢 |
44 musi 2024-11-23 20:17:09 +08:00 via iPhone @livid @luckykelan #43 本来还在问题讨论范畴现在直接人生攻击了 |
45 luckykelan 2024-11-23 20:22:51 +08:00 @musi 你不会真的觉得你跟楼主的对话是在问题讨论吧?啊,那楼主为何发出“这交流环境也太恶劣了.”的感慨啊,你俩讨论啥呢? |
46 musi 2024-11-23 22:03:57 +08:00 via iPhone @luckykelan #45 没事,只要你没否认你人生攻击就行,只要你承认你违反这个社区规则就行 |
47 luckykelan 2024-11-23 23:51:53 +08:00 @musi 我当然否认了,我都不知道人生攻击是什么意思,你是说人身攻击吗? |
48 musi 2024-11-24 00:00:28 +08:00 via iPhone @luckykelan 哦,原来你只否认人生攻击但不否认人身攻击呀。那没事了,另外你这说话的语气比我也好不了多少,咱俩大哥别说二哥 |
49 musi 2024-11-24 00:05:19 +08:00 via iPhone @luckykelan 好了,到这就差不多了,看不顺眼直接 block ,没必要在网上吵架。最近线下事件那么多,我可不想因为一点小事暴发什么事件。 |