背景提要:肥肥是某大一计科生，在上大学之前没有接触过代码。现在仅有的知识储备只有CS50,CS61B,CS61C这几门课的内容，但是感觉离实践都比较远，再加上想要自己给自己写个Agent小玩具，所以Agent开发做中学记录串，堂堂连载!(つд⊂)

肥肥的计划是写一个能够分析自己日记的心理咨询agent，两天来的进展:
两天来的进展:
1.熟悉了Langchain,LangSmith的使用
2.使用Langchain的Chroma集成写了一个存储日记的向量数据库，采用了联合存储的结构，构建了两个collection，第一个collection存储日记的原文本，第二个collection存储日记的概括、情感、模式识别等信息支持模糊检索，同时metadata中存储日期和我自己写的一些枚举表来支持过滤。两个collection共用基于原文本哈希得到的id来实现联合检索。

目前数据库能够跑通，但是测试的时候发现切分上传的文本时，模型会丢弃不少的原文本。
ver1.1:我解除了max_token的限制，但是结果没有改善，说明不是token数量导致的截断问题。
ver1.2:我调整了提示词，强调了切分的原则，问题仍然没有改善。
ver1.3:我将日记切分拆分为了两步，先概括整体结构，再依据结构切分，仍然没有改善。
ver1.4:调整了用于结构概括的模型的提示词，仍然没有改善|ー` )

目前我找到了jina ai的一篇关于长文本分块的研究，正在研读中

让大模型切分？不是个好主意。用规则或者启发式更可控。

火山的那个知识库切片的时候也是一样的问题|∀ﾟ蹲一手

现在大一都如此恐怖了吗，我大一的时候还在阿巴阿巴( ﾟ∀。)7

可以问一下po是在国内还是国外就读的吗

>>No.68416080
我查了许多LLM-based的方法，发现即使抛开生成效率不谈，许多也是在demo上表现良好，一落地都各有各的问题( ﾟ∀。)不过我一开始单纯是懒人想法想让大模型包办

>>No.68416208
在国内读的( ﾟ∀。)其实只是本质水货一个

在查解决方法的时候看到了一个和我相反的思路，小块文本向量化，大段保留，先检索小段再定位的大块(Small-to-Big Retrieval)，和我的概括大块，然后先定位大块再检索小块的路子反过来了( ﾟ∀ﾟ)mark一下，有精力的话我会尝试一下这种方法再评估一下效果

屈服了，打算直接拿Langchain的SemanticChunker拿来用了( ﾟ∀。)不自己造轮子了。后续会试着拿Hichunk拿来对比一下，看看论文天花乱坠，实际效果如何

>>No.68417662
我拿我自己日记测试的时候发现大多数情况下SemanticChunker的切分几乎和依据日期直接切分的结果一样，我在想这是因为我日记本身同一天内语意相关性就比较强，还是说我需要调一下参数。目前打算扩大一下用于测试的文本范围试一下。

今天晚上什么也没干( ﾟ∀。)
为什么呢，因为我发现今晚我写的test不知道为什么导入不了我的src了，但明明昨天晚上还能正常运行。
我一开始怀疑是我今天写的代码有问题，于是我删除了今天写的代码，然后再重启了一次解释器，import还是会报错。
我猜可能是vscode抽风了，因为我以前写Verilog的时候也遇到过这样的情况，满屏幕报错但其实代码正常跑没问题。
所以我跑了一遍，得，报错了( `д´)
于是我显示修改了sys.path再试了一遍，还是不行。
最终我启动了终极武器:重启，行了?!!
(因为不知道哪来的敏感词，我排了好久，改之又改，文风变成了诡异的一坨)

>>No.68423801
但我当然不满足于重启，万一下次又不行了怎么办？
所以我加上了我今天写的测试，再试了一遍，又报错了。
我备份了原本的测试文件之后再次重启，结果重启之后报错的代码又跑成功了?(;´Д`)
经过我多次控制变量的实验之后我终于找到了问题。
我猜测应该是vscode在工作区中打开文件的时候会直接把当前文件所在目录当成根目录?(也有可能是错误的推断)
前面的测试中有时报错有时不报错是因为我后来反复的测试过程中有时打开整个项目文件夹，有时只打开test文件夹，有时只打开单独的test文件，而打开整个项目文件夹时系统目录就是正确的，大概是这个原因?
总之现在在我每次都是打开整个项目文件夹之后就再也没遇到过报错了。
但是为什么以前我没遇到这样的问题呢( ﾟ∀。)真是奇怪啊

继日记的数据库之后我完成了对其它材料的向量化数据库以及对ai对话的摘要数据库。
我在写日记文本的存储时，因为我的初衷仅仅是分析我的日记，而我比较熟悉我的日记的一些情况，所以我在存储的过程中就对我的日记做了一些预处理，采取了生成式的方法来进行类似于摘要优先检索的策略(不过实际不是摘要那么简单，我日记中我熟知的一些议题之类的东西我也有写一个预分析的处理)最后形成的一个双联的数据库(我没有用RAPTOR的原因也是这个，相对来说这是对我日记定制性很强的一个策略)
但是在写其它材料的存储时我最开始也想用预处理的思路，但是遇到了没法构建预处理的方法的问题，因为我无法预计输入的材料是什么类别，进而像日记那样写专门的预处理思路。我考虑过直接写一个巨大的metadata字段，里面是我依据CBT,人本主义等流派写的一大堆枚举类型让llm去选择，但是最后考虑到性能的原因放弃了，最终采取了朴素的small2bi方法。
对于对话记录的摘要，我最开始考虑让ai给我一些做结构化摘要的思路，但ai提供的回答都不是很理想。最后我考虑了心理咨询中常用的咨询记录格式，最终从SOAP，DAP，PAIP三种方法中选择了PAIP(problem,assessment,intervention,plan)的格式让llm去做摘要。

这些内容里反而RAG的实现不是问题最大的，反正我只是照着现成的思路抄( ﾟ∀。)本质脚本小子小肥。
大多数的时间花在了如何从心理咨询的角度去给数据库做一个适应，比如非日记的其它材料我想了很久最后还是放弃了，只不过把做过的尝试留档也许以后会有用到的机会，比如一些复合的检索策略之类的，还有就是对话记录的摘要怎样去提取出真正重要的信息而不是草率的摘要，这些内容我觉得相比起查知识，去哪查才是真的更重要( ´д`)不然很多时候查了很多资料都是在重复造轮子做无用功。

我发现用ai写测试会很爽( ﾟ∀。)好像很省工作量，写一些对小部件的短平快的基本测试很提高效率