有关之前设想的两种方法。
1 扩展上下文
见效甚微。我初始量化包含了后三条消息，发现AI消息占比多，干扰大。舍弃AI消息，收集到的对话内容依旧单一，对话质量并没有显著提升。
2 队列
会增加成本。不会主动索取匹配历史，没有新内容。
最近量化的内容逐渐多了起来，历史记录占不到1mb，量化内容就占了几十Mb，几乎大于app本体。
每次读取会将量化文本直接拿到物理内存里，手机会直接闪退。虽然流式可以避免这个问题，但长远来看，维护量化内容会越来越困难。
我开始怀疑量化文本这种方法在检索历史消息的应用中究竟是否“完备”
现在的方法，假设初始量化的当前用户消息是“钥匙”，历史消息中的每个条目就是“锁”，要拿着钥匙一个一个去匹配。
舍弃所有AI消息的量化如何呢？–对减少空间占用的作用不明显，语义的高维量化只和消息条目有关，占用空间只是少了AI的那一半，不会因为用户消息少就降低。
而用户消息单独匹配，更适合于专业问答，虽然用户更应占更多权重，但在此场景下也没什么提升。
看来完全依靠量化确实行不通。也许应该换种方法了。
此方悬停