Langchain-Chatchat如何实现文档访问统计？了解知识使用情况

Langchain-Chatchat 如何实现文档访问统计？洞察知识使用的新视角

在企业知识库日益庞大的今天，一个看似简单却常被忽视的问题是：我们辛辛苦苦整理的技术文档、操作手册和项目报告，到底有没有人看？

很多组织投入大量资源构建内部知识平台，却发现员工依然习惯“遇到问题就问同事”，而不是去查资料。这背后的根本原因，并非员工懒惰，而是缺乏对知识使用情况的可见性——没人知道哪些文档有用、哪些早已过时，更不知道哪里存在知识盲区。

正是在这种背景下，Langchain-Chatchat这类基于大语言模型（LLM）的本地化智能问答系统脱颖而出。它不仅让员工能用自然语言快速获取信息，更重要的是，它的底层架构天然支持一种关键能力：文档访问统计。通过记录每一次检索行为，系统可以告诉我们“谁在查什么、哪份文档最受欢迎”，从而真正实现知识资产的可度量、可优化。

但这个功能并不是开箱即用的按钮，而需要我们深入理解其技术逻辑并进行合理设计。那么，它是如何实现的？我们又该如何利用现有组件构建一套轻量高效的统计机制？

要回答这个问题，得先看看 Langchain-Chatchat 是怎么工作的。整个流程其实是一条清晰的数据链：从文档加载开始，到分块、向量化、存储，再到用户提问时的检索与回答生成。每一步都由 LangChain 框架中的模块协同完成。

其中最关键的环节之一就是Retriever（检索器）。当用户提出一个问题，系统会将问题编码为向量，在向量数据库中查找最相似的文本片段。这些片段来自原始文档的分块结果，而每个块都携带了元数据，比如source_file、page_number或自定义标签。这正是实现访问追踪的基础。

举个例子：

from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=300, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) split_docs = text_splitter.split_documents(documents) for doc in split_docs: doc.metadata["source_file"] = "network_config_manual.pdf" doc.metadata["access_count"] = 0 # 初始化计数

这里我们在分块阶段主动注入了两个字段：一个是文档来源，另一个是访问次数。虽然access_count当前只是占位符，但它暗示了一个可能性——我们可以在每次命中该文本块时动态更新这个值。

不过要注意，向量数据库本身不负责维护这种状态。也就是说，不能指望 FAISS 或 Chroma 自动帮你累加访问量。我们必须在应用层做点“手脚”：在检索返回结果后、生成回答前，插入一段逻辑来提取被命中文档的信息，并持久化统计记录。

这就引出了一个核心设计思路：把访问统计作为一个中间件嵌入到 RetrievalQA 链中。

LangChain 提供了灵活的链式编程能力，尤其是 LCEL（LangChain Expression Language），允许我们像搭积木一样组合组件。我们可以这样改造默认流程：

from langchain_core.runnables import RunnablePassthrough from langchain_core.output_parsers import StrOutputParser def log_retrieval(inputs): docs = inputs["context"] # 提取所有被检索到的源文件名 sources = [doc.metadata.get("source_file") for doc in docs if "source_file" in doc.metadata] # 异步写入日志或数据库 write_access_log(user_id="current_user", queried_sources=sources) return inputs # 继续传递上下文 # 构建增强型问答链 qa_chain = ( {"context": retriever, "question": RunnablePassthrough()} | RunnablePassthrough.assign(context=log_retrieval) # 插入日志逻辑 | prompt | llm | StrOutputParser() )

在这个结构中，log_retrieval函数充当了一个“拦截器”的角色。每当有文档被检索出来用于回答，它就会被触发，提取出source_file字段并写入日志系统。由于这是纯 Python 代码，你可以自由决定记录哪些信息：时间戳、用户身份、IP 地址、甚至会话 ID，都可以根据安全策略选择性保留。

当然，性能必须考虑。如果每次访问都同步写数据库，可能会拖慢响应速度。因此建议采用异步方式处理日志，例如使用concurrent.futures或消息队列（如 Redis Queue、Celery）将统计任务解耦出去，确保主流程不受影响。

另一个容易被忽略的问题是重复计数。同一个用户连续问两次类似问题，可能反复命中同一份文档。如果不加控制，会导致数据失真。合理的做法是在会话级别做去重，比如设置一个时间窗口（如10分钟内同一用户+同一文档只记一次），或者结合语义相似度判断是否属于重复查询。

至于存储方案，也不必一开始就上复杂的数据仓库。对于中小规模部署，一个简单的 SQLite 表就足够了：

CREATE TABLE document_access ( id INTEGER PRIMARY KEY AUTOINCREMENT, source_file TEXT NOT NULL, accessed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, user_id TEXT, session_id TEXT ); -- 查询某文档的总访问次数 SELECT source_file, COUNT(*) as total_views FROM document_access GROUP BY source_file ORDER BY total_views DESC;

有了这些基础数据，管理员就能回答几个关键问题：
- 哪些文档是“明星内容”，被频繁引用？
- 哪些上传后从未被打开过？是不是可以归档或删除？
- 某个新上线的产品手册发布一周了，但访问量几乎为零——是不是培训没跟上？

更有意思的是，结合用户身份认证后，还能做更细粒度的分析。比如发现某个部门总是查同一份运维指南，那很可能说明相关流程不够自动化，或者新人培训不足；再比如某些高访问文档伴随着低满意度反馈（可通过后续问卷收集），那就值得优先更新。

但这还不是全部。Langchain-Chatchat 的一大优势在于本地化部署。所有处理都在内网完成，敏感信息不会外泄。这对金融、医疗、军工等行业至关重要。你不用担心员工问“XX项目的预算细节”时，问题被传到第三方服务器上。这也意味着，你的访问日志同样保留在可控范围内，符合 GDPR、等保等合规要求。

当然，本地部署也有挑战。比如需要足够的 GPU 资源运行 LLM 推理，轻量级模型如 ChatGLM3-6B-int4 或 Qwen-7B-Chat 是常见选择。它们在语义理解能力上虽不及 GPT-4，但在特定领域知识问答中表现足够稳定。而且正因为专注私有知识，反而不容易产生“幻觉”——因为回答主要依赖检索到的上下文，而非模型自身的记忆。

说到这里，不得不提一下整个系统的典型架构：

[用户界面] ↓ (输入问题) [LangChain 流程引擎] ├── [文档加载器] → 读取 TXT/PDF/DOCX ├── [文本分割器] → 分块处理 ├── [Embedding 模型] → 向量化 └── [向量数据库] ← 存储/检索 ↓ [本地 LLM] ← 接收问题 + 上下文 → 生成回答 ↑ [访问日志中间件] ← 记录检索行为

可以看到，访问日志中间件并没有破坏原有流程，而是作为非侵入式的观察者存在。它不改变任何业务逻辑，只默默收集行为数据。这种松耦合设计使得功能可插拔：你可以随时开启或关闭统计，不影响核心问答能力。

回到最初的目标——了解知识使用情况。这套机制带来的价值远超简单的“点击量排行榜”。它实际上为企业建立了一套知识健康监测系统。想象一下，每个月自动生成一份《知识库活跃度报告》，列出 Top 10 热门文档、Top 10 沉睡文档、各团队的知识消费模式……这些洞察可以直接驱动决策：要不要重构某份高频访问的手册？要不要给低使用率的内容负责人发提醒？

未来，这条路径还可以走得更远。比如引入简单的机器学习模型，基于历史访问模式预测下周可能被查询的知识主题，提前推送相关内容；或者结合 NLP 分析提问语句的情感倾向，识别出“找不到答案”的挫败感，进而标记潜在的知识缺口。

但即便现在，只需几行代码改造，就能让一个静态的知识库变成一个动态的、可感知的智能系统。这正是 Langchain-Chatchat 的魅力所在：它不只是一个问答工具，更是一个通往可度量知识管理的入口。

当你下次看到有人问“上次那个接口文档在哪？”的时候，也许你可以微笑着告诉他：“别急，我来看看最近谁查过它。”