Yuxu Ge
Article · 2024-10-19

Sensitive Word Protection in RAG Systems: End-to-End Practice from Upfront Detection to Real-Time Interception

RAG systems can detect sensitive content in user queries at different stages. Four critical timing points and their trade-offs are common:

  1. User input stage (upfront detection): Filter sensitive words the moment a user submits a question. The main advantage is immediacy—violations can be blocked at the source, preventing entry into computationally expensive retrieval and generation stages, thereby reducing system overhead. Users receive prompt feedback with preset rejection responses, improving interaction efficiency. The drawback is dependence on predefined word lists or detection models, risking both false negatives (users evade the list through unconventional phrasing) and false positives. Overall, upfront detection kills risk at the source and is the most direct and effective approach. This is the strategy we strongly recommend in this article.

  2. Pre-retrieval detection: Perform detection after receiving user input but before executing RAG retrieval. It sits just one step apart from upfront detection—if input-stage blocking failed, a second check can happen before querying the vector database or retrieval index. This still avoids unnecessary downstream LLM calls and long-text processing, though it is slightly slower than immediate input blocking; preprocessing operations may already have executed. The pros and cons resemble upfront detection: it prevents violations from entering the model but wastes some computation before retrieval. If the system rewrites or expands queries, detecting after rewriting can compensate for gaps in the input-stage policy. Yet if earlier input-stage detection is available, there is typically no reason to wait until pre-retrieval to block.

  3. Pre-LLM generation detection: Check whether the question (or question plus retrieved results) contains sensitive content after document retrieval but before sending to the language model for generation. By this point, the system has already completed vector retrieval and document fetching; a second check of the query is possible. The downside is substantial: retrieval resources and time have been spent; if sensitive words are found and generation halts, all prior effort is wasted. Moreover, if sensitive content appears clearly in the user query, it could have been blocked much earlier with no reason to delay until here. The only potential benefit is an edge case where retrieved content makes an otherwise innocuous question sensitive—rare in practice. Overall, placing detection before generation is suboptimal because users have waited considerable time only to receive no answer.

  4. Post-generation review (output moderation): Audit and filter the language model's response after it is generated. This is post-hoc review, often used to supplement upfront strategies and ensure final output contains no violations. For chatbots, output review can intercept content the model attempts to generate. However, as a sole mechanism it is problematic: first, the model may have already generated a violation (even if not shown to the user, it poses compliance risk and problematic content persists); second, users told after waiting for a full response that it cannot be provided ruins experience. In our scenario, if the user's question itself violates policy, it should be rejected outright rather than allowing the model to generate and then filter. Thus output review serves mainly as a safety backstop (preventing accidental oversights) rather than handling known violations. By comparison, upfront detection excels in timeliness, cost, and safety. Once a user input is identified as touching insider information or other sensitive content, the system immediately returns a preset rejection, protecting compliance and avoiding wasted resources. We therefore clearly recommend placing sensitive word detection at the user input stage for immediate interception. This does not preclude adding one more review pass at final output as a safety net, but upfront blocking should be the first line of defense.

Sensitive Word Dictionary Design and Maintenance

To implement upfront sensitive word detection, a high-quality sensitive word corpus is essential. Dictionary design requires attention to format, matching strategy, and maintenance mechanisms:

Industry commonly uses Trie-based or Aho-Corasick automata algorithms for high-performance sensitive word matching. After constructing an automaton containing all sensitive words, these methods scan input text in roughly linear time to locate all occurrences. For very large dictionaries (hundreds of thousands to millions of entries), Aho-Corasick is particularly suitable. These approaches can also combine fuzzy matching strategies (for example, pre-expanding words with multiple pronunciations into variants before insertion). For smaller dictionaries, direct iteration matching may suffice, but as the corpus grows, adopting such algorithms is recommended to ensure detection accuracy and efficiency.

Implementing Fast-Fail Interception in RAG Frameworks

Having settled on upfront sensitive word detection strategy, we must integrate it into RAG system architecture to achieve fast-fail—immediately terminating retrieval and generation when a violation is found, without proceeding downstream. Below we illustrate interception placement and mechanism within a typical RAG flow:

Typical RAG question-answering flow: User submits question → System retrieves relevant documents from knowledge base → Sends documents and question to language model for generation → Returns answer to user. To add sensitive word interception to this pipeline, we modify it as follows:

  1. Insert upfront interception node: Before user queries enter the retrieval component, add a sensitive word detection node. This node receives user input text and applies the word list and matching algorithm described above.

  2. Check for violations: If the detection node finds protected sensitive words or triggers a prohibited topic, immediately mark as violation.

  3. Trigger fast-fail: Upon violation detection, the system skips vector retrieval, LLM invocation, and all downstream steps, instead following the fast-fail path: generate and return a preset response to the user. For example, output the fixed phrase: "We apologize; your question touches on sensitive information and we cannot provide an answer," then end the flow.

  4. Normal path continues: If the detection node finds no sensitive words, the input is deemed safe and enters the regular RAG retrieval flow: retrieve relevant knowledge and generate an answer.

  5. Output and follow-up: For cases caught by upfront interception, output uniform rejection content; for normal answers, the model output can pass through a final content review to prevent accidental mention of restricted information (this is a separate safety layer addressing output-level violations, not the focus here).

The above flow ensures that when users pose illegal inquiries, the system shortcuts the primary pipeline, guaranteeing timely response while avoiding potentially harmful model outputs. Architecturally, this is equivalent to adding a gate to the RAG pipeline: input passes through the gate (no sensitive words matched) and is admitted to the main path; otherwise it is diverted to a safe exit.

In practical engineering, this upfront interception takes several forms:

if contains_sensitive(user_input):
    return PRESET_RESPONSE
else:
    result = RAG_chain(user_input)  # 正常执行检索和生成
    return result

This method is clear and intuitive and works in any framework. For projects using off-the-shelf frameworks like LangChain or Haystack, you can manually add this logic before invoking the chain.

Whichever integration method we use, the core principle is completing safety validation as early as possible, keeping bad input out. Simultaneously, ensure that when interception occurs, the system returns correct, policy-compliant fixed responses. For financial scenarios, this phrasing typically undergoes compliance review, such as: "We apologize; per regulatory requirements, we cannot answer your question" or "We apologize; your question touches on sensitive information and we cannot assist." Such responses are both courteous and firm, conveying why service is unavailable while divulging nothing unnecessary.

Worth noting: beyond building custom sensitive word blocking, some existing language model content safety solutions can contribute at the input stage. For example, Meta's LlamaGuard can detect harmful content in user input. Such general solutions can serve as auxiliary safeguards, but financial compliance scenarios still require fine-tuned custom word lists to catch specific violations. Combining multiple techniques thus builds a comprehensive safety perimeter.

Code Implementation Example

Below we show simplified code snippets implementing upfront sensitive word detection interception in the LangChain framework, along with an example of organizing a sensitive word corpus. This example assumes an existing RAG question-answering chain (such as RetrievalQA) with a corresponding vector retriever and LLM, focusing on inserting the sensitive word filtering logic.

# 1. 定义敏感词列表和检测函数
sensitive_words = ["内幕消息", "内幕交易", "非法集资", "操纵市场", "洗钱"]  # 示例敏感词列表
# 为提高匹配准确度，可将列表中的每个词转换为正则模式或统一大小写等，这里简单直接匹配
def contains_sensitive(text: str) -> bool:
    """判断文本是否包含任一敏感词"""
    for w in sensitive_words:
        if w in text:
            return True
    return False

# 2. 构建 RAG QA 链（假设已初始化 retriever 和 llm）
from langchain.chains import RetrievalQA
qa_chain = RetrievalQA.from_chain_type(llm=llm, chain_type="stuff", retriever=retriever)

# 3. 在提问时进行前置检测并实现 fast-fail 拦截
user_query = "请提供关于某股票的内幕消息"  # 用户输入示例
if contains_sensitive(user_query):
    response = "很抱歉，您的提问涉及敏感信息，无法提供解答。"  # 预设固定回应
else:
    # 未命中敏感词，执行正常的 RAG 流程
    response = qa_chain.run(user_query)

print(response)

The code above first defines a simple sensitive word list and a detection function contains_sensitive. In production, this function can be extended to support regex, case-insensitivity, homophone conversion, and more complex matching, with the dictionary loaded from external configuration. We then build a LangChain RetrievalQA chain for knowledge retrieval and question-answering. Before actually calling the chain to process the user question, we use an if-statement to check whether user_query contains sensitive words. If yes, we directly set the response to a preset rejection phrase and skip the qa_chain call; if no, we proceed normally through the chain to fetch an answer.

For more advanced usage, we can leverage LangChain's RunnableLambda or custom Chain to encapsulate the logic above into part of a pipeline:

from langchain.schema import RunnableLambda, RunnableSequence

# 封装敏感词检测为一个 RunnableLambda
filter_runnable = RunnableLambda(lambda query:
    "很抱歉，您的提问涉及敏感信息，无法提供解答。" if contains_sensitive(query) else query
)

# 将检测步骤与 QA 链组合为一个流水线
pipeline = RunnableSequence([filter_runnable, qa_chain])
result = pipeline.invoke(user_query)

In the snippet above, we construct a filter_runnable that outputs a fixed reply if input contains sensitive words, otherwise returns the input unchanged. We then use RunnableSequence to chain filtering and the QA chain into a pipeline. Note that if filter_runnable returns a rejection string instead of the original query, the qa_chain following it might treat it as a new question. Thus, to truly achieve short-circuiting, more elaborate RunnableSequence customization is possible—for example, letting the filter step return a special object checked within the pipeline. For demonstration purposes we simplify here, emphasizing how to embed interception logic.

Through the code above, we realize complete end-to-end real-time sensitive word detection at the user question stage. When users input illegal queries like "insider information," the system immediately returns a fixed response without any model inference; when input is normal, the system follows standard procedures to retrieve knowledge and generate answers. This upfront sensitive word protection strategy erects a solid safety barrier for financial intelligent advisory systems, safeguarding compliance while boosting system efficiency and user experience.

Conclusion

In financial intelligent advisory applications powered by large language models, content safety and compliance are paramount. Through the topic "Sensitive Word Protection in RAG Systems: End-to-End Practice from Upfront Detection to Real-Time Interception," we have detailed how to deploy sensitive word filtering mechanisms within a system to intercept violations. We compared the merits and drawbacks of introducing detection at different stages, clarifying the advantages of upfront detection; we described methods for designing and iteratively maintaining high-quality sensitive word corpora to counter evolving evasion tactics; and we provided implementation strategies and code examples for achieving fast-fail interception within the LangChain framework.

By advancing sensitive word detection to the input stage, we can respond to problematic queries in milliseconds, avoid wasted resources and potential violations. This practice is relevant to any compliance-conscious conversational AI system. Looking ahead, we can further leverage large models' content understanding to explore intelligent sensitive content detection (for instance, using small classifier models to identify oblique query intent) and finer-grained policies (such as deciding whether to outright refuse or issue a warning based on violation severity). Yet however techniques evolve, upfront interception grounded in sound word lists and clear rules will remain the first and most critical defense for safeguarding AI application safety.

© 2026 Yuxu Ge ·