Langchain-Chatchat 问题推荐功能开发思路
在企业级智能问答系统日益普及的今天，一个常被忽视的问题浮出水面：用户不知道该问什么。尤其当知识库庞大、内容专业性强时，面对空白输入框，即使是熟悉业务的员工也可能陷入“提问困境”。这种现象在金融合规文档查询、医疗指南检索或法律条文咨询等场景中尤为明显。
这正是Langchain-Chatchat这类本地化知识库系统亟需突破的关键点——从被动响应走向主动引导。而“问题推荐”功能，正是实现这一跃迁的核心抓手。
我们不妨先抛开传统的“总-分-结构”，直接切入技术实现的本质。想象这样一个流程：当用户打开系统首页，还未输入任何内容时，界面上已浮现几个精心设计的问题卡片：“如何申请内部项目经费？”、“2024年差旅报销标准有哪些变化？”、“新员工入职培训包含哪些模块？”。这些并非随机生成，而是系统基于已有文档和使用行为，主动“想”出来的高价值问题。
要实现这一点，我们需要深入理解 Langchain-Chatchat 的底层机制，并在其架构缝隙中植入新的智能逻辑。
整个系统的运转依赖三大支柱：LangChain 框架的编排能力、向量数据库的语义检索能力、以及本地大模型的生成能力。它们共同构成了一个闭环的知识服务引擎。但这个引擎目前仍是“反应式”的——只有接收到输入，才会启动输出。我们的目标是让它具备一定的“前瞻性”。
首先来看 LangChain 的角色。它不只是简单的链式调用工具，更是一个可编程的认知管道。通过RetrievalQA或自定义Chain，我们可以控制信息流动的方向与形态。比如，在常规问答流程之外，完全可以构建一条独立的“预热链”（warm-up chain），专门用于生成推荐问题。
from langchain.prompts import PromptTemplate from langchain.chains import LLMChain # 定义提示模板：让LLM根据文档摘要内容，生成5个用户可能感兴趣的问题 prompt_template = """ 你是一个问题生成器。请根据以下文档摘要内容，生成5个用户可能感兴趣的问题。 要求： 1. 问题要具体、有意义； 2. 覆盖不同方面（定义、流程、优势、案例等）； 3. 使用中文。 摘要内容： {summary} 请直接列出问题，每行一个问题。 """ PROMPT = PromptTemplate(template=prompt_template, input_variables=["summary"]) question_gen_chain = LLMChain(llm=llm, prompt=PROMPT)这段代码看似简单，却揭示了一个重要理念：我们可以把 LLM 当作“知识探针”来使用。不是用来回答问题，而是反过来，让它去“设想”问题。这种方式比单纯提取关键词高级得多——它能捕捉到概念之间的关联性，从而提出更具探索性的问题。
当然，也不能完全依赖生成式方法。对于结构清晰的文档（如带目录的 PDF 手册），直接解析章节标题往往更高效且准确。例如：
from PyPDF2 import PdfReader def extract_toc_from_pdf(pdf_path): reader = PdfReader(pdf_path) toc = [] for page in reader.pages: text = page.extract_text() # 简单规则匹配“第X章”、“一、”等结构 if "第" in text and "章" in text: line = text.strip() if len(line) < 50: # 排除正文干扰 toc.append(line) return toc # 基于目录生成问题 def generate_questions_from_toc(toc_items): questions = [] for item in toc_items: # 规则模板：“请介绍[章节名]的主要内容？” q = f"请介绍 {item} 的主要内容？" questions.append(q) return questions[:5]这种方法成本低、稳定性高，特别适合制度类、手册类文档。但它缺乏灵活性，无法覆盖非结构化文本中的隐含知识点。
因此，最理想的策略是混合推荐机制：
- 对有明确结构的文档，优先采用目录解析 + 关键词扩展；
- 对纯文本或复杂内容，启用 LLM 自动生成；
- 在系统运行一段时间后，叠加热度统计，将高频问题置顶。
这三种方式可以并行执行，结果统一归集到缓存层（如 Redis）中，供前端按需拉取。
再来看向量数据库的作用。很多人只把它当作检索工具，其实它还能用于问题相似度分析。假设我们已经积累了一批历史提问，就可以将其全部向量化并存入 FAISS。每当新生成一个问题时，先做一次近邻搜索，避免重复推荐语义相近的内容。
from langchain.embeddings import HuggingFaceEmbeddings import numpy as np embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2") def is_too_similar(new_q, existing_questions, threshold=0.85): vecs = embeddings.embed_documents([new_q] + existing_questions) query_vec, candidate_vecs = vecs[0], vecs[1:] sims = np.dot(candidate_vecs, query_vec) / ( np.linalg.norm(candidate_vecs, axis=1) * np.linalg.norm(query_vec) ) return np.max(sims) > threshold这样的去重机制虽然简单，但在实际应用中非常有效，能显著提升推荐多样性。
至于本地 LLM 推理部分，则需要关注资源调度问题。生成推荐问题属于后台任务，不应影响主线程的响应速度。建议的做法是：
- 将问题生成任务放入异步队列（如 Celery）；
- 在文档入库完成后自动触发；
- 生成结果持久化存储，避免每次重启都重新计算；
- 支持手动刷新和定时更新（如每日凌晨批量处理）。
@celery.task def async_generate_recommendations(doc_id): summary = get_document_summary(doc_id) questions = question_gen_chain.run(summary).split('\n') filtered = [q.strip() for q in questions if q.strip() and not is_too_similar(q, get_global_question_pool())] save_recommendations(doc_id, filtered)这样既保证了用户体验，又实现了智能化运营。
前端交互设计同样关键。推荐区域不宜喧宾夺主，通常放在输入框下方或侧边栏即可。以卡片形式展示 3~5 个问题，支持点击后自动填充并提交查询。更重要的是提供关闭按钮，尊重用户的操作习惯。
此外，别忘了建立反馈闭环。记录哪些推荐问题被点击、哪些被忽略，甚至允许管理员标记“优质问题”，这些数据都可以反哺推荐算法优化。例如，长期未被点击的问题类型应逐步降低权重。
从工程实践角度看，有几个容易踩坑的地方值得提醒：
- 不要在首次加载时实时生成问题，否则页面会卡住。务必提前准备好候选集；
- 避免过度个性化。在没有足够用户行为数据前，统一推荐比“猜你喜欢”更稳妥；
- 注意隐私边界。即使要做个性化推荐，也应匿名化处理用户 ID，仅保留会话级上下文；
- 控制 GPU 资源占用。如果使用 GPU 加速生成，记得设置超时和并发限制，防止 OOM。
最后回到系统架构本身。Langchain-Chatchat 的模块化设计为功能扩展提供了极大便利。问题推荐模块本质上是一个“轻量级 Agent”，它不参与核心问答流程，而是作为一个辅助组件存在。它的输入是文档内容或摘要，输出是一组字符串列表，接口清晰、职责单一。
这也意味着它可以轻松替换或升级。未来若引入用户画像、会话意图识别等功能，只需调整推荐策略的权重分配即可，无需重构整个系统。
真正有价值的技术改进，往往不是堆砌复杂模型，而是在合适的环节加入恰到好处的智能。问题推荐功能看似微小，实则是连接“知识沉睡”与“知识激活”的桥梁。它让系统不再只是一个冰冷的问答机器，而更像是一个懂你所需、主动引路的知识伙伴。
随着更多上下文感知能力的融入——比如结合当前时间（“是否要查看本月考勤政策？”）、用户角色（“你是HR吗？这里有招聘流程指南”）——这类系统的智能化水平还将持续进化。而这，或许才是企业知识管理迈向真正可用、好用的开始。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
