Langchain-Chatchat能否支持Markdown语法高亮输出？

Langchain-Chatchat能否支持Markdown语法高亮输出？

在企业级AI应用日益普及的今天，如何在保障数据隐私的前提下，构建一个既智能又“好看”的本地问答系统，成了许多技术团队关注的核心问题。尤其是在开发、运维、技术支持等场景中，用户不仅希望得到准确的答案，更期望这些答案——特别是包含代码示例的回答——能以清晰、结构化的方式呈现。

这正是Langchain-Chatchat面临的实际挑战之一：它作为一款基于 LangChain 框架打造的开源本地知识库问答系统，能否真正实现Markdown 语法高亮输出？这个问题看似简单，实则牵涉到模型能力、前端渲染、后端传输和整体架构设计等多个层面。

我们不妨从一个常见场景切入：一位工程师上传了一份内部 API 文档 PDF，然后提问：“请用 Python 写一个调用订单接口的示例。”理想情况下，系统返回的不应是一段挤在一起的纯文本代码，而是一个带有缩进、关键字着色、语言标识的代码块。否则，哪怕逻辑正确，阅读体验也会大打折扣。

那么，Langchain-Chatchat 能做到吗？答案是：完全可以，但需要各环节协同配合。

从模型输出到前端渲染：一条完整的 Markdown 流水线

要实现语法高亮，本质上是要打通“生成 → 传递 → 渲染”这三个关键链路。任何一个环节断裂，最终效果都会打折扣。

大模型能不能“写对”格式？

首先得看 LLM 自己争不争气。如果模型压根不会按 Markdown 格式输出，后面再怎么优化也是白搭。

好消息是，当前主流的中文大模型如ChatGLM3-6B、Qwen-7B、Baichuan2-7B等，在经过高质量指令微调后，已经具备较强的结构化文本生成能力。只要提示词（prompt）设计得当，它们完全能理解“请用 Python 代码块返回结果”这类要求。

比如你可以这样写 prompt：

“你的回答必须使用中文。若涉及代码，请使用标准 Markdown 语法包裹，并明确标注语言类型，例如：```python。”

这种约束性指令非常有效。Langchain-Chatchat 支持自定义prompt_template，因此可以在配置中直接加入此类规范，强制模型输出符合预期的格式。

from langchain.prompts import PromptTemplate template = """ 你是一个技术助手，请根据以下上下文回答问题。 要求： 1. 回答简洁准确； 2. 若涉及代码，请使用 Markdown 语法包裹，并标明语言类型； 3. 使用中文回复。 上下文: {context} 问题: {question} 回答: """ prompt = PromptTemplate(template=template, input_variables=["context", "question"])

这样一来，模型输出的内容大概率会包含类似这样的片段：

```python import requests url = "https://api.example.com/orders" headers = {"Authorization": "Bearer your-token"} response = requests.get(url, headers=headers) print(response.json())

只要这个基础成立，后续的一切才有可能。 --- ### 前端能不能“看懂”并“美化”？ 有了正确的 Markdown 输出，接下来就看前端会不会“打扮”了。 Langchain-Chatchat 的 Web UI 通常基于 **Gradio** 或 **Streamlit** 构建，这两者都内置了对 Markdown 的原生支持。更重要的是，它们默认集成了像 [highlight.js](https://highlightjs.org/) 这样的轻量级语法高亮库。 以 Gradio 为例，当你使用 `gr.Markdown()` 或 `gr.ChatInterface` 返回一段包含三重反引号的字符串时，框架会自动识别其中的代码块，并根据语言标签应用相应的颜色方案。 ```python import gradio as gr def chatbot_response(message, history): return """ 以下是推荐的 Python 数据清洗方法： ```python import pandas as pd df = pd.read_csv('data.csv') df.dropna(inplace=True) print(df.head())

该脚本将自动移除缺失值。
“”“

demo = gr.ChatInterface(fn=chatbot_response)
demo.launch()

运行这段代码，你会发现返回的代码块不仅有背景色区分，关键字也实现了基础着色——这一切无需额外配置，开箱即用。 当然，如果你追求更高阶的视觉表现，也可以替换为 [Prism.js](https://prismjs.com/) 或集成 Monaco Editor 实现更接近 IDE 的编辑器体验，但这属于可选增强项，非必要条件。 --- ### 后端会不会“破坏”原始内容？ 最容易被忽视的一环是：**后端服务是否完整传递了原始 Markdown 字符串？** FastAPI 是 Langchain-Chatchat 常用的后端框架，它本身对文本处理很友好。但如果中间层做了 HTML 转义（如把 `<` 变成 `&lt;`）、过滤特殊字符或启用富文本净化机制（如 bleach），就可能导致三重反引号失效，前端无法正确解析代码块。 解决办法很简单：确保 API 接口返回的是原始字符串，不对内容做任何预处理。例如： ```python @app.post("/query") async def handle_query(request: QueryRequest): result = qa_chain({"query": request.question}) return {"answer": result["result"]} # 直接返回，不转义

同时，在 Nginx 或其他代理层也应避免启用自动 XSS 过滤规则，以免误伤合法的 Markdown 结构。

当然，安全也不能完全放弃。虽然要保留 Markdown 原文，但仍建议在前端做一定程度的内容 sanitization，防止恶意注入。可以使用如DOMPurify或sanitize-html对响应内容进行清洗，只允许安全的标签通过。

整体架构中的协同机制

Langchain-Chatchat 并不是一个孤立的组件，而是依托于LangChain 框架构建的一套完整 RAG（检索增强生成）流程。整个系统的运作链条如下：

[用户提问] ↓ [Web UI] → [FastAPI 后端] ↓ [文档检索：FAISS + Embedding] ↓ [拼接 Prompt + 上下文] ↓ [LLM 生成回答] ↓ [返回至前端，渲染为 Markdown]

在这个流程中，LangChain 扮演了“粘合剂”的角色，将文档加载、切分、向量化、检索与生成模块无缝连接起来。而 Markdown 高亮的支持，则主要发生在最后两个阶段：生成和展示。

值得一提的是，系统使用的 embedding 模型（如m3e-base、bge-small-zh）和向量数据库（如 FAISS）虽然不直接影响渲染效果，但它们决定了能否准确召回包含代码示例的相关文档。换句话说，如果知识库里的技术文档本身就用了 Markdown 编写，且 chunk 切分合理，那么模型在生成时更容易参考到规范格式，从而提升输出一致性。

实际应用场景的价值体现

为什么我们要如此重视 Markdown 高亮？因为它直接关系到系统的可用性和专业度。

想象一下这两个对比场景：

• 无格式输出：
  “你可以使用requests库发送GET请求……import requests url=’…’ headers={…} response=requests.get(url,headers=headers)…”

用户需要自己脑补哪部分是代码，还要复制到编辑器里才能看清结构。

• 带高亮输出：
  ```python
  import requests

url = “https://api.example.com/data”
headers = {“Authorization”: “Bearer xxx”}
response = requests.get(url, headers=headers)
print(response.json())
```
一眼就能看出这是 Python 代码，关键字高亮、缩进清晰、可直接复制使用。

这种差异在以下场景中尤为明显：

1. 企业内部 API 文档查询系统

开发者不再需要翻阅冗长的 Confluence 页面，只需自然语言提问即可获得带示例代码的回答，极大提升效率。

2. 技术支持平台

运维人员可以通过问答方式获取脚本模板，如日志分析、批量操作命令等，减少重复劳动。

3. 教学助教系统

教师可将讲义导入系统，学生提问时不仅能获得解释，还能看到格式规范的代码演示。

4. 私有化 AI 编程助手

在金融、军工等敏感行业，不能使用公网 AI 工具的情况下，本地部署的 Langchain-Chatchat 成为替代方案，而良好的排版能力是其能否被接受的关键。

设计细节决定成败

尽管整体支持良好，但在实际部署中仍有一些细节需要注意，稍有不慎就会导致“明明写了代码块却没高亮”。

✅ 模型训练数据需包含 Markdown 示例

如果所用 LLM 在训练过程中接触的 Markdown 内容较少，可能无法稳定输出规范格式。建议优先选择在 GitHub、技术博客等富含代码的数据上训练过的模型。

✅ 合理设置文本切分粒度

对于含有代码的技术文档，建议采用更大的chunk_size，并结合separator策略保留完整代码块边界。例如：

splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=100, separators=["\n\n", "\n", "```"] # 在代码块边界优先切分 )

这样可以尽量避免代码被拆散在两个 chunk 中，影响语义完整性。

✅ 前端样式微调不可少

即使启用了 highlight.js，也可能出现长代码行溢出容器的问题。建议添加 CSS 修复：

.code-block { white-space: pre-wrap; overflow-x: auto; background-color: #f4f4f4; padding: 10px; border-radius: 4px; font-family: 'Courier New', monospace; }

让代码既能换行又能横向滚动，兼顾移动端和桌面端体验。

✅ 安全防护不能松懈

虽然要保留 Markdown 原文，但必须防范潜在的 XSS 风险。可在前端使用DOMPurify.sanitize()对输出内容进行过滤：

const clean = DOMPurify.sanitize(dirtyMarkdown); document.getElementById('output').innerHTML = marked(clean);

既保证了安全性，又不影响正常渲染。

总结：不只是“能不能”，更是“好不好”

Langchain-Chatchat完全支持 Markdown 语法高亮输出，这不是一个功能开关，而是一整套工程实践的结果。它的实现依赖于：

• 使用具备结构化生成能力的大模型；
• 设计合理的 prompt 引导输出格式；
• 前端框架正确解析并渲染代码块；
• 后端服务完整传递原始文本；
• 整体架构中各组件协同工作。

更重要的是，这种支持不仅仅是“能显示”，而是能否做到稳定、美观、安全、易用。当一个本地部署的问答系统不仅能保护数据隐私，还能提供媲美商业产品的交互体验时，它才真正具备落地价值。

未来，随着更多高性能小模型的涌现和前端渲染能力的增强，我们甚至可以期待更进一步的功能：比如自动检测代码语言、动态插入执行按钮、支持交互式调试等。但就目前而言，Langchain-Chatchat 已经迈出了坚实的第一步——它不仅能回答问题，还能把答案“说清楚”。