日志

有关之前设想的两种方法。

1 扩展上下文
见效甚微。我初始量化包含了后三条消息,发现AI消息占比多,干扰大。舍弃AI消息,收集到的对话内容依旧单一,对话质量并没有显著提升。

2 队列
会增加成本。不会主动索取匹配历史,没有新内容。

最近量化的内容逐渐多了起来,历史记录占不到1mb,量化内容就占了几十Mb,几乎大于app本体。

每次读取会将量化文本直接拿到物理内存里,手机会直接闪退。虽然流式可以避免这个问题,但长远来看,维护量化内容会越来越困难。

我开始怀疑量化文本这种方法在检索历史消息的应用中究竟是否“完备”

现在的方法,假设初始量化的当前用户消息是“钥匙”,历史消息中的每个条目就是“锁”,要拿着钥匙一个一个去匹配。

舍弃所有AI消息的量化如何呢?–对减少空间占用的作用不明显,语义的高维量化只和消息条目有关,占用空间只是少了AI的那一半,不会因为用户消息少就降低。

而用户消息单独匹配,更适合于专业问答,虽然用户更应占更多权重,但在此场景下也没什么提升。

看来完全依靠量化确实行不通。也许应该换种方法了。


此方悬停
相册 小说 Ai