匆匆那年

传统情况下我们使用axios调用接口，将response转换成json后就可以直接使用了。 但是使用大模型的时候，因为以下几种原因，传统模式已经不再试用了。 对应响应内容还有多少服务器端自己也不清楚 响应内容可能很多，用户不可能长期等待服务端的响应，所以需要有多少数据就传输多少数据。 这种边生成数据边给客户端输出的这种形式成为流式输出。 实测发现使用axios即使将相应设置成responseType: 'stream'也没什么效果，使用原生的fetch可以轻松应对。 async function streamDeepSeekResponse(prompt) { const response = await fetch('https://api.deepseek.com/chat/completions', { method: 'POST', body: JSON.stringify({ token: 'token', }) }); if (!response.ok) { throw new Error(`API request failed with status ${response.status}`); } const reader = response.body.getReader(); const decoder = new TextDecoder(); let result = ''; Read more…

常规的文本替换很简单，直接replace替换即可，但是遇到大文件就麻烦了，直接获取全部的文本内容不现实，太占用内存甚至可能导致程序崩溃，这个时候就需要流式读取文件内容，也就是一次读取文件的一部分，跟蚂蚁搬家似的，那样每次占用内容的空间就不大了，程序能一直正常处理。 流式处理的话需要将每次读取一定长度（必须需要大于待替换的文本长度）的数据块，可以取一个固定值，比如1M，足够了。 流式处理可能存在的问题 采用分块处理会带来一个问题，如果取出的数据的开头或结尾刚好把一个待替换的文本切开了怎么，如图所示 第三个“待替换文本”就刚好一部分在“数据块1”，另一部分在“数据块2”，在处理“数据块1”的文本替换的时候就只能找到两个符合条件的文本，也就只能替换掉两个，在处理“数据块2（假设和数据1类似）”的文本替换的时候也只能找到并替换到两个符合条件的文本，但实际上就是数据1和数据2整体而言，少替换了一个“待替换文本”——“待替换文本3”。 解决问题思路 这种场景我们应该怎么处理呢？ 在处理“数据块1”的时候，我们可以确定的是先把前面两个好处理的替换文本给替换掉，然后余下不够分的部分和后面的“数据块2”合并在一起成为“新的数据块2”，然后跟处理“数据块1”的方法一样，对“新的数据块2”进行替换操作，此时“待替换文本3”就能被找到并替换了，如果也有余下的部分，我们也将它合并到下面的“新的数据块3”，以此类推即可。 解决问题实现 具体的实现方式如下 const fs = require('fs'); const { Transform } = require('stream'); class ReplaceTransform extends Transform { constructor(searchRegex, replaceString, options) { super(options); this.searchRegex = searchRegex; this.replaceString = replaceString; this.tailPiece = ''; this.replaceTailPieceLength = Math.max(…[…searchRegex.toString().matchAll(/\((?!\?)/g)].map(match => match.index)) || 0; } _transform(chunk, encoding, callback) Read more…