三年 Telegram 群聊如何变成可查询知识库

三年 Telegram 群聊里藏着税务局实际处理时长、被替换的表格和不再推荐的会计，但 Telegram 搜索只能匹配已知关键词，无法回答问题。把历史导出、转为文档后交给 NotebookLM 就能解决，作者已为真实群聊搭建了完整 pipeline。

这个 pipeline 把看似杂乱的聊天记录变成了可被大模型理解的知识库。整个过程听起来简单，实际操作却充满细节。作者没有停留在概念层面，而是针对真实三年群聊数据完成了从导出到查询的全链路。结果是，用户不再需要记住具体词，就能直接问出答案。

Telegram 导出文件解析存在多处格式陷阱

Telegram 官方提供了聊天记录导出功能，主要输出 JSON 和 HTML 两种格式。JSON 包含完整消息元数据，包括发送时间、用户 ID、回复关系和媒体附件，但结构并不平坦。消息类型多样，文本、图片、文件、语音、转发内容混杂在一起，解析时很容易遗漏边缘情况。

HTML 版本更适合人类阅读，却给自动化处理带来额外麻烦。消息被包裹在层层 div 标签中，时间戳有时以 data 属性存在，有时直接显示为文本。回复链在 HTML 中通过 CSS 类体现，程序需要额外逻辑才能重建对话上下文。作者在实践中发现，群聊中常见的 @ 提及、表情包和贴纸都会以不同格式出现，如果不针对性处理就会丢失关键信息。

更棘手的是多媒体内容。三年群聊里可能有数百张图片和文档链接，JSON 中只记录文件 ID 而非实际内容。解析器必须决定是跳过这些附件，还是尝试提取可读文本。作者列出了几处常见陷阱：消息编辑记录会被单独存为一条新消息，导致时间线重复；系统通知如用户加入、退出也会混入正常对话；群名称变更和置顶消息在导出文件中位置不固定。

这些陷阱要求解析代码必须足够健壮。作者的方案是先用 JSON 作为主数据源，再结合 HTML 补充格式化文本，最终生成干净的时间线序列。整个解析阶段耗费了大量调试时间，却为后续步骤打下可靠基础。（本节约 380 字）

把聊天记录转为可查询文档的核心步骤

第一步是把原始聊天记录完整导出。Telegram 桌面版允许选择特定群组和时间范围，导出的 JSON 文件体积可能达到几十 MB。拿到文件后，解析器按时间顺序遍历每一条消息，过滤掉纯系统通知和无意义重复内容。

接下来是文档切分。作者没有把所有消息塞进一个大文件，而是按主题和时间窗口将对话聚合成多个独立文档。每个文档包含一段连续对话、参与者信息和关键事实摘要。这种切分既保留了上下文，又避免单文档过长导致 LLM 丢失细节。

文本清洗是重要一环。聊天记录里充满缩写、表情符号、语音转文字错误和口语化表达。作者编写了针对群聊的清洗规则，去除多余换行、统一时间格式，并尝试将图片描述或文件名称补充到文本中。最终生成的文档采用 Markdown 格式，标题清晰、段落分明，适合 NotebookLM 这样的工具阅读。

整个流程被封装成可重复运行的脚本。作者强调，导出后不要一次性处理全部三年数据，而是分批验证每个阶段输出是否符合预期。这样能在早期就发现解析错误，避免后期大规模返工。（本节约 350 字）

NotebookLM 在群聊知识库上的实际表现

NotebookLM 被选为最终查询引擎。作者将处理后的文档集合上传后，测试了几个真实问题。结果显示，它能准确回答“税务局上次处理类似备案实际花了多久”“哪张表格已经替换了旧版本”“大家后来都不再推荐哪个会计”这类具体查询。

与普通搜索不同，NotebookLM 理解了对话中的因果关系。它能从分散在不同月份的消息里拼凑出完整答案，而不是简单返回包含关键词的片段。作者观察到，当问题涉及时间演变时，模型会主动引用不同时期的消息，并给出时间线总结。

局限同样存在。对于高度碎片化的闲聊，或者只有一两句提及的事实，NotebookLM 有时会给出“不确定”或编造轻微细节。作者通过增加更多上下文文档和调整提示词缓解了这个问题。总体而言，在三年群聊这种中等规模知识库上，NotebookLM 的表现超出预期，尤其适合需要快速获取历史共识的场景。

实际使用中，用户不再需要记住谁在哪天说过什么，只需用自然语言提问即可。这大大降低了团队内部知识获取的门槛。（本节约 340 字）

打包策略才是决定检索效果的关键

作者反复强调，整个项目的设计难点不在解析，而在于如何打包文档。单纯把所有消息丢给模型会导致上下文窗口爆炸和检索精度下降。有效的打包策略需要平衡信息密度和独立性。

具体做法包括按主题聚类、控制单个文档长度、为每个文档添加摘要和元数据标签。作者尝试过多种打包粒度，最终发现以“周”为单位、结合关键事件锚点的方案效果最好。这样既能让模型看到足够上下文，又避免单个文档过于庞大。

打包还涉及去重和重要性排序。群聊中反复出现的闲聊会被压缩，而包含具体数字、日期和人名的消息则被提升权重。作者发现，好的打包能让 NotebookLM 的回答质量提升一倍以上，而解析准确率即使只有 95% 也不会造成致命影响。

这一发现颠覆了许多人“解析最重要”的直觉。真正决定知识库可用性的，是文档如何被组织成模型能高效检索的形态。（本节约 320 字）

微信群聊导出与查询的相似痛点对比

中文用户更熟悉微信群聊，它面临几乎完全相同的困境。微信同样没有强大的语义搜索，只能按关键词匹配已知词，无法回答“上次讨论的方案最终怎么定下来的”这类问题。群聊记录导出也存在限制，官方工具功能较弱，第三方工具又面临合规和数据隐私风险。

微信聊天记录主要以本地数据库形式存储，导出后得到的是加密或特殊格式的文件，解析难度比 Telegram JSON 高出不少。但核心流程可以复用：导出、解析、清洗、切分成文档、再喂给支持中文的 LLM 或 NotebookLM 类工具。

作者认为，中文团队面临的实际需求更迫切。很多公司内部决策、税务合规细节、供应商反馈都散落在微信群里。复用 Telegram 项目中的打包策略和文档生成逻辑，能快速搭建类似知识库。区别主要在于解析器需要针对微信数据库格式重写，而后续的文档处理和查询环节几乎可以直接搬用。

对中文用户来说，隐私是额外考量。把群聊记录上传到 NotebookLM 需要评估数据敏感度，必要时可选择本地运行的开源替代方案。（本节约 350 字）

对中文开发者构建内部知识库的启示

这个案例给中文开发者提供了清晰路径：不要被聊天记录的杂乱吓倒，先完成可靠的导出和解析，再把精力重点放在文档打包和检索策略上。整个 pipeline 可以用 Python 快速实现，核心依赖只有 Telegram API、简单 JSON 处理库和 NotebookLM。

实际落地场景包括技术团队的历史决策库、财务群的税务知识沉淀、产品讨论的版本演进记录。开发者可以进一步扩展，支持多群聊合并、自动更新增量消息、甚至对接企业内部知识库系统。

更重要的是思维转变：聊天记录不再是只能人工翻看的存档，而是可以被机器理解并随时查询的资产。中文开发者在落地时可优先选择支持长上下文和中文理解较好的模型，同时注意数据合规。

作者的实践证明，即使只有一个人也能在几天内搭建出可用系统。关键是动手去做，而不是等待完美工具出现。（本节约 330 字）

参考来源

• Making three years of a Telegram group chat queryable