首页

最近更新.rss.xml

Transformer 没有一个"离散、可验证、逐步更新"的状态来维护计数。
Transformer 没有一个"离散、可验证、逐步更新"的状态来维护计数。

更好的解决方案

在经过一段时间的尝试和摸索之后，我发现就是结合文本分段，再加上一个上下文的一个后期的坐标修正是能够达到最佳的一个体验的。
例如给每一个段落分配一个id交给大模型，并且让他输出的时候携带相关文本前面一段文本和后面一段文本，输出示例： {before:'交给',target:'大模型',after:',并且',snippet:'片段id'}​
这样基本能达到 95% 以上的准确率了。
上面是一些拙见，欢迎指正交流更好的方案
实际应用场景，文档校对demo演示：
​ ​
​ ​

如何解决这个问题？

但是有些场景是依赖大模型输出对应的下标的，这似乎又是必须依赖大模型数数了。
例如利用大模型标记文档中的所有写错了的文字。
既然直接数数不行，但是如果你让大模型去复述文本却能得到很高的准确率。
那么自然而然的就能想到，将文本先按字拆分，然后将下标和文字一起给大模型，例如 ： 1:大 2:模 3:型 4:不 5:会 6:数 7:数​ 这样之后输出的下标准确率就会飙升。
下面是一个简单的尝试，显而易见的 带坐标输入 的方案准确率更好 ​ ​
下面是一个简单的尝试，显而易见的 带坐标输入 的方案准确率更好 ​ ​
实际应用场景，文档校对demo演示：
上面是一些拙见，欢迎指正交流更好的方案
这样基本能达到 95% 以上的准确率了。
例如给每一个段落分配一个id交给大模型，并且让他输出的时候携带相关文本前面一段文本和后面一段文本，输出示例： {before:'交给',target:'大模型',after:',并且',snippet:'片段id'}​
在经过一段时间的尝试和摸索之后，我发现就是结合文本分段，再加上一个上下文的一个后期的坐标修正是能够达到最佳的一个体验的。
但是他不会数数！不信您可以试试发一段文本给大模型让他输出一下文本中的所有名词的位置，十有八九是会有错误的位置。
那么自然而然的就能想到，将文本先按字拆分，然后将下标和文字一起给大模型，例如 ： 1:大 2:模 3:型 4:不 5:会 6:数 7:数​ 这样之后输出的下标准确率就会飙升。
既然直接数数不行，但是如果你让大模型去复述文本却能得到很高的准确率。
例如利用大模型标记文档中的所有写错了的文字。
但是有些场景是依赖大模型输出对应的下标的，这似乎又是必须依赖大模型数数了。
对于这个问题我不是大模型专家，不知道究竟是为什么，但是事实上就是他数数不太行
现在这个时代似乎大模型什么都能干，每天自媒体都是大模型干翻这个那个，前端又被杀了。

最近实践

​note​ https://z2h.cn/hanzi 字帖生成网站，田字格
​note​ amd 利用 npu 的办法：https://ryzenai.docs.amd.com/en/latest/inst.html https://lemonade-server.ai/ https://github.com/amd/gaia?tab=readme-ov-file 主要还是 lemonade-server ，gaia 也是连接的 gaia （直接安装 gaia 会自动安装 lemonade-server
​好文推荐​ https://vue-bits.dev/ 非常绚酷的 vue 动画库
​好文推荐​ 浏览器插件开发最佳实践 https://wxt.dev/guide/installation.html

AI 会写网页了，但还不会用中文字体

最近发现一个很有意思的现象。
很多前端其实不知道，网页是可以直接引用远程字体的。
而知道远程字体的人，往往又不敢用中文字体。
原因很简单——中文字体包太大了。
一个字体十几兆、几十兆都很正常。前阵子在技术群看到有同行说，他们网站光字体流量，一个月就烧掉了两万多块。
​ ​
后来大家开始做字体裁剪——把用不到的字砍掉，只保留页面上出现的字。
但这条路，我发现还有两个问题没解决。
第一个问题：用户真的会访问你网站所有页面吗？
大多数时候不会。用户可能只看两三个页面就走了，但传统方案要求他下载整个网站对应的那份字体子集——可能有几千个字。
第二个问题：AI 生成的内容怎么办？
现在越来越多网页是 AI 实时生成的。聊天框里用户问一句，AI 返回的文字当场渲染到页面上。
这些字，在构建的时候根本不存在。 你没法提前裁剪你不知道的字。
于是我做了一个实验：
让字体像代码一样，按需加载。
页面出现什么字，就裁剪什么字。 后面出现新的文字，再继续增量加载。
效果很直接——页面只出现"静心茶舍"四个字时，它就只下载这四个字的字形，大约 6KB。不是 6MB，是 6KB。
我把这个能力做成了 WebFont。
它不是构建时一次性裁剪整个网站，而是运行时、按页面真实出现的文字动态裁剪。后端返回的动态内容、AI 实时生成的内容，都能按需加载对应字形，DOM 一变就自动补齐新字。
最近，我又给它增加了一个 AI Skill。
现在 AI 生成网页时，不仅能自动用上中文字体，还能自动做好中文排版——行距给到 1.8、中英文之间加空格、正文首行缩进，甚至连禅意、科技、奢侈这些风格，AI 都知道该配什么字体、什么节奏。
我越来越觉得：
未来的 AI，不仅要会写网页，还要会设计网页。
而中文字体这一关，它迟早得过。
WebFont：github.com/2234839/web-font ｜ 在线体验：webfont.shenzilong.cn （2020 年上过阮一峰周刊，开源 6 年）
​ ​
最近发现一个很有意思的现象。
很多前端其实不知道，网页是可以直接引用远程字体的。
而知道远程字体的人，往往又不敢用中文字体。
原因很简单——中文字体包太大了。
一个字体十几兆、几十兆都很正常。前阵子在技术群看到有同行说，他们网站光字体流量，一个月就烧掉了两万多块。
后来大家开始做字体裁剪——把用不到的字砍掉，只保留页面上出现的字。
但这条路，我发现还有两个问题没解决。
第一个问题：用户真的会访问你网站所有页面吗？
大多数时候不会。用户可能只看两三个页面就走了，但传统方案要求他下载整个网站对应的那份字体子集——可能有几千个字。
第二个问题：AI 生成的内容怎么办？
现在越来越多网页是 AI 实时生成的。聊天框里用户问一句，AI 返回的文字当场渲染到页面上。
这些字，在构建的时候根本不存在。 你没法提前裁剪你不知道的字。
于是我做了一个实验：
让字体像代码一样，按需加载。
页面出现什么字，就裁剪什么字。 后面出现新的文字，再继续增量加载。
效果很直接——页面只出现"静心茶舍"四个字时，它就只下载这四个字的字形，大约 6KB。不是 6MB，是 6KB。
我把这个能力做成了 WebFont。
它不是构建时一次性裁剪整个网站，而是运行时、按页面真实出现的文字动态裁剪。后端返回的动态内容、AI 实时生成的内容，都能按需加载对应字形，DOM 一变就自动补齐新字。
最近，我又给它增加了一个 AI Skill。
现在 AI 生成网页时，不仅能自动用上中文字体，还能自动做好中文排版——行距给到 1.8、中英文之间加空格、正文首行缩进，甚至连禅意、科技、奢侈这些风格，AI 都知道该配什么字体、什么节奏。
我越来越觉得：
未来的 AI，不仅要会写网页，还要会设计网页。
而中文字体这一关，它迟早得过。
WebFont：github.com/2234839/web-font ｜ 在线体验：webfont.shenzilong.cn （2020 年上过阮一峰周刊，开源 6 年）
WebFont：github.com/2234839/web-font ｜ 在线体验：webfont.shenzilong.cn （2020 年上过阮一峰周刊，开源 6 年）
可能很多人都不知道，网页其实是可以引用远程网络字体的。
我这里提出一个方案，那就是动态的去进行裁剪。 动态裁剪字体。 这可能是。 动态的裁见中文字体，然后增量的去。 拉取渲染显示。 得到最佳的中文字体展示体验。 并且是最少的流量消耗来节约服务器的流量成。
另外就是。 还有些文字，他。 可能不是前端在构建的时候就能确定的，它必须是它是后端返回的文字，所以它是动态的那这个时候很多的前端可能就不知道怎么解决这个中文字写的问题。
你使用字珠这些东西，可能是针对全整个网站去进行一个字体裁剪。 但是用户真的会用到所有的中文字体吗？我觉得这是一个不见得的事情。 他访问手有些有很多用户可能只访问某几个页面，但是他却要下载你整个网站的中文字体哦。 这个体体量可能也是不小的。
再进一步知道可以裁剪字体的人。 这个可能是更少的。 但是他们也许没有想过。 怎么去处理动态文字的一个问题。
而知道这个事情的人。 可能也没有想过去使用中文字体，因为中文字体包实在太大了。十兆来自于记十兆的中文字体包对用户的流量是难以接受。
可能很少人知道网页上是可以。 引用远程的网络字体的。