什么体量需要 4 核 8g 的服务器

试过了，个人当玩具可以，直接上生产不行

建议用隐藏光纤连接

主要还是看产品的客群是谁
B 端主要还是价值为先，你能给公司带来多少盈利还是能给公司节省多少成本，这才是老板(最终买单者)关心的，至于你的界面多好看用户体验多好并不能打动老板

移动端没有适配，手机上打开基本不可用

对比一下圆周旅记呢

“未来若达成盈利”

这是个 feature

我摘了眼镜失败率就高达 90 以上

copy as curl 然后导入

我说一个：舍得花钱用最新的大模型

我如果不上班会有一大堆事做，这些事都是这些年以上班没时间作为借口攒下的

企业的账号也会封吗

把上下文长度砍了成本自然就限制了

@musi #6

依靠向量的 RAG 整体流程一般就是
1. 拆分文档
2. 文档转向量
3. 向量入库
4. 向量检索
5. LLM 根据检索到的数据进行生成

其中 1 4 的准确性都会影响到 5 的结果，加上 LLM 本身存在的幻觉，导致最终结果更加不可控

@ovate 依靠 LLM 向量检索在文本转向量期间还是会受到 LLM 窗口大小的制约，所以需要对源文档进行拆分。所以引入第一个问题：
一、怎么拆分文档？
1. 根据 LLM 窗口大小进行自动化拆分？
最开始的方法，因为拆分文档就是因为 LLM 窗口限制，所以自然而然的想到根据窗口大小进行拆分。但是在实践中发现，直接根据窗口大小不会联系上下文，同样的一个词在不同的上下文中的意思差别很大
2. 根据上下文拆分?
如何保证拆分的每一段文档都处于一个上下文中？上下文很大要怎么处理？

拆分完文档转向量入库这一步是最简单的，选取一个支持向量存储的数据库然后调用 API 就可以

入库完之后需要检索，这就是第二个问题：
二、如何检索？
直接通过余弦相似度计算向量？查出来有多个结果应该取哪个？相似度越高真的就越符合原问题吗？

试试高德的地图小程序

v 站反买，别墅靠海