在VS中用C#和ASP.NET MVC搭建本机LLM工程：AIGC准确性校验与推理链路控制

1. 为什么要在 VS 里用 C# 和 ASP.NET MVC 搭一套本机 LLM 工程

先把话说在前头：这套东西不是给"调个 API 就完事"的人准备的。如果你只是想接个云端大模型接口，那根本用不着 ASP.NET MVC，一个控制台程序几十行代码就搞定了。我之所以选择在 Visual Studio 里用 C# + ASP.NET MVC 来搭本机 LLM 工程，核心原因只有一个——我需要一个能完全掌控推理链路、能对 AIGC 输出做工程级校验、并且能长期维护的本地化系统。

这个定位决定了技术选型的走向。本机 LLM 意味着模型跑在本地或者局域网内的推理服务上，不依赖外部网络，数据不出内网。ASP.NET MVC 意味着我需要一个成熟的 Web 层来承载交互界面、任务调度和结果展示。C# 则是因为整个工程要和现有的 .NET 生态打通，包括数据库访问、文件处理、串口通信、上位机对接这些活儿，用 C# 是最顺手的。

那 AIGC 的准确性到底难在哪？我踩过的坑告诉我，问题从来不在模型本身有多强，而在于工程层面缺少对生成结果的约束和验证机制。模型会一本正经地胡说八道，会在长文本里悄悄丢失关键信息，会在多轮对话中逐渐偏离原始意图。这些问题的根源不是模型能力不够，而是整个工程链路里没有设计"校验节点"和"纠偏机制"。

所以这套工程的整体思路可以概括为一句话：把 LLM 当成一个能力很强但不可完全信任的组件，用工程手段在它前后加上护栏。前端负责意图澄清和输入规范化，中端负责推理调度和上下文管理，后端负责结果校验、事实比对和输出格式化。ASP.NET MVC 的三层结构天然适合承载这种分工。

适合谁来参考？如果你是有一定 C# 和 .NET 基础，想在本机环境里搭建一套可控的 LLM 应用，并且对生成质量有明确要求，那这篇内容就是写给你的。如果你只是想快速体验一下大模型对话，那直接用现成的客户端工具就行，没必要折腾这一套。

2. 整体架构设计与核心思路拆解

2.1 三层架构的职责划分与选型逻辑

ASP.NET MVC 的 Model-View-Controller 结构在这里不是拿来当摆设的，每一层都有明确的职责边界。我在设计的时候，把整个 LLM 工程分成了三个核心层次，每一层解决不同的问题。

Model 层承担的是"数据与推理"的职责。这里放的是 LLM 推理服务的封装、上下文管理、Prompt 模板、结果校验器。我试过把推理逻辑直接写在 Controller 里，结果就是代码膨胀到没法维护，一个 Controller 文件超过两千行，改一个参数要翻半天。后来老老实实把推理相关的全部下沉到 Model 层，Controller 只负责调度，代码立刻清爽了。

View 层负责的是"交互与呈现"。这里不只是把结果展示出来那么简单，还要处理流式输出的逐字渲染、生成进度的实时反馈、以及校验结果的标注显示。我用的是 Razor 视图配合少量 JavaScript 做局部刷新，没有上前后端分离那一套，因为本机工程的交互复杂度不高，Razor 的开发效率反而更高。

Controller 层是"调度与编排"的中枢。它接收用户请求，调用 Model 层的推理服务，拿到结果后交给校验器，最后把校验通过的结果传给 View。Controller 里不写任何推理逻辑，只做流程编排和异常处理。

注意：三层之间的依赖方向必须是单向的，Controller 依赖 Model，View 依赖 Model，但 Model 绝对不能反向依赖 Controller 或 View。我见过有人在 Model 里直接调 HttpContext 拿用户信息，这种写法在单元测试的时候会让你痛不欲生。

2.2 本机推理服务的接入方式选择

本机 LLM 的接入方式有好几种，我逐一试过，最后选了一个折中方案。直接进程内加载模型权重的方式，C# 生态的支持还不够成熟，而且模型加载会吃掉大量内存，和 Web 服务的生命周期管理冲突。纯 HTTP 调用独立推理服务的方式最灵活，但多了一层网络开销。

我最终采用的是独立推理进程 + 本地 HTTP 通信的方案。推理服务单独跑一个进程，通过本地回环地址的 HTTP 接口暴露能力，ASP.NET MVC 这边用 HttpClient 去调用。这样做的好处是推理进程崩了不影响 Web 服务，模型可以独立重启和切换，而且推理服务的资源占用和 Web 服务解耦，方便做资源限制。

通信协议上我用的是简单的 JSON over HTTP，没有上 gRPC，因为本机通信的延迟本来就很低，gRPC 带来的性能优势在这个场景下可以忽略，反而增加了调试的复杂度。请求体里包含 prompt、温度参数、最大生成长度、停止词这些字段，响应体里包含生成文本、token 统计和推理耗时。

2.3 AIGC 准确性问题的工程化拆解

AIGC 的准确性问题，如果笼统地说"模型不准"，那根本没法解决。我把它拆成了四个可工程化处理的子问题。

第一个是事实性错误，模型生成了与事实不符的内容。这个问题靠模型自身很难根治，工程上的应对是在输出后做事实比对，把生成内容里的关键实体抽取出来，和本地知识库做交叉验证。

第二个是上下文漂移，在多轮对话中模型逐渐偏离原始意图。应对方式是在每轮对话前重新注入核心意图摘要，而不是简单地把历史对话全部塞进去。

第三个是格式不稳定，模型输出的结构时好时坏。应对方式是用结构化 Prompt 约束输出格式，并在解析失败时触发重试。

第四个是长文本信息丢失，生成长内容时中间部分的关键信息被遗漏。应对方式是把长生成任务拆分成多个短任务，每个短任务独立校验后再拼接。

这四个子问题对应四套工程机制，后面会逐一展开。

3. 核心细节解析与实操要点

3.1 推理服务的封装与参数调优

推理服务的封装我写了一个LlmInferenceService类，核心方法是一个异步的GenerateAsync。这个方法的参数设计很关键，直接决定了生成质量的上限。

温度参数我默认设的是 0.3，而不是常见的 0.7。原因是我这套工程主要面向的是需要准确性的场景，比如技术文档生成、代码辅助、数据提取，这些场景下创造性不是首要目标，稳定性才是。温度调到 0.3 之后，同样的输入基本能得到相似的输出，这对调试和验证太重要了。如果你要做创意类的内容生成，可以调到 0.7 到 0.9，但那样就需要更强的后置校验。

最大生成长度我设的是 2048 个 token，这个数字是权衡后的结果。设太小，长内容生成会被截断；设太大，推理时间线性增长，而且模型在长生成的后半段质量会明显下降。2048 这个长度大概对应一千多个汉字，对于大多数单次生成任务够用了。超过这个长度的需求，我会走分段生成的路子。

停止词我配了一组，包括常见的结束标记和自定义的分隔符。停止词的作用是让模型在生成到特定位置时主动停下来，避免生成多余的废话。我实测下来，配好停止词能让输出干净不少，省去很多后处理的工作。

public async Task<LlmResponse> GenerateAsync(LlmRequest request) { var payload = new { prompt = request.Prompt, temperature = request.Temperature ?? 0.3f, max_tokens = request.MaxTokens ?? 2048, stop = request.StopWords ?? new[] { "\n\n\n", "###" } }; var response = await _httpClient.PostAsJsonAsync( "http://127.0.0.1:8080/generate", payload); response.EnsureSuccessStatusCode(); return await response.Content.ReadFromJsonAsync<LlmResponse>(); }

提示：HttpClient 一定要用 IHttpClientFactory 来管理，不要每次 new 一个。我一开始图省事直接 new HttpClient，跑了一段时间之后发现端口耗尽的问题，排查了半天才定位到。用工厂模式管理连接池，这个问题就没了。

3.2 Prompt 模板的工程化管理

Prompt 不能散落在代码各处，必须集中管理。我建了一个PromptTemplate目录，每个场景一个模板文件，用占位符标记需要动态填充的部分。模板文件用纯文本格式，方便非技术人员也能参与调整。

模板的结构我固定成四段：角色定义、任务描述、约束条件、输出格式。角色定义告诉模型它应该以什么身份来回答，任务描述说清楚要做什么，约束条件列出不能做什么，输出格式规定结果的结构。这四段缺一不可，尤其是约束条件和输出格式，很多人写 Prompt 只写前两段，结果就是输出质量飘忽不定。

举个例子，做技术文档摘要的模板是这样的：角色定义是"你是一名资深技术编辑"，任务描述是"对以下技术文档进行摘要"，约束条件是"只保留核心技术要点，不添加原文没有的信息"，输出格式是"用三个要点概括，每个要点不超过五十字"。这样约束下来，输出的稳定性比随便写一句"帮我总结一下"要高出一个量级。

模板的版本管理也很重要。我每次调整模板都会记录版本号和调整原因，因为 Prompt 的改动对输出质量的影响非常大，没有版本记录的话，出了问题根本不知道是哪个改动导致的。

3.3 上下文管理与意图保持机制

上下文管理是 AIGC 准确性里最容易被忽视的环节。很多人就是把历史对话一股脑塞进 prompt，对话轮次一多，模型就开始犯迷糊。我的做法是分层管理上下文。

第一层是核心意图，用一两句话概括用户到底想要什么，这部分永远放在 prompt 的最前面，每轮都重新注入。第二层是近期对话，只保留最近三到五轮，再早的就丢弃。第三层是关键信息摘要，把更早的对话压缩成要点，附在核心意图后面。

这样做的好处是 prompt 的长度可控，而且核心意图始终在最显眼的位置，模型不容易跑偏。我实测过，用分层管理之后，十轮以上的对话里模型偏离意图的概率明显下降。

意图摘要的生成我用的是另一个轻量级的 LLM 调用，专门做摘要任务，温度设成 0，保证摘要的稳定性。摘要的 prompt 里明确要求"只提取事实性信息，不做推断和补充"，避免摘要本身引入错误。

3.4 结果校验器的设计与实现

结果校验是这套工程的核心价值所在。我设计了三种校验器，串行执行，任何一个不通过都会触发重试或降级处理。

格式校验器检查输出是否符合预期的结构。如果要求输出 JSON，就尝试解析，解析失败直接判定不通过。这个校验器最简单但最有效，能拦下大量格式跑偏的情况。

事实校验器把输出里的关键实体抽取出来，和本地知识库做比对。实体抽取我用的是规则加模型结合的方式，规则负责识别明显的实体模式，模型负责处理规则覆盖不到的情况。比对的时候不是要求完全一致，而是检查是否存在明显矛盾。比如知识库里说某个参数是 100，输出里说是 500，这就是矛盾，判定不通过。

一致性校验器检查输出内部是否自相矛盾。这个校验器会扫描输出里的数字、日期、专有名词，看同一个概念在不同位置的说法是否一致。我遇到过模型在开头说"支持三种模式"，结尾却说"两种模式可选"的情况，这种内部矛盾靠人工检查很容易漏掉，用校验器就能自动抓出来。

public class ValidationPipeline { private readonly List<IValidator> _validators; public ValidationPipeline() { _validators = new List<IValidator> { new FormatValidator(), new FactValidator(_knowledgeBase), new ConsistencyValidator() }; } public ValidationResult Validate(string output, ValidationContext context) { foreach (var validator in _validators) { var result = validator.Validate(output, context); if (!result.IsValid) return result; } return ValidationResult.Pass(); } }

注意：校验器本身也可能出错，尤其是事实校验器依赖的知识库如果不准确，会把正确的输出误判为错误。所以校验不通过的时候不要直接丢弃输出，而是标记出来交给人工复核，或者触发一次带更强约束的重试。

4. 实操过程与核心环节实现

4.1 项目结构搭建与依赖配置

在 Visual Studio 里新建项目的时候，我选的是 ASP.NET Web Application (.NET Framework) 里的 MVC 模板。虽然 .NET Core 更新，但我这套工程要和一些老的 .NET Framework 类库对接，所以还是用了 Framework 版本。如果你没有这个约束，用 .NET 6 以上的版本会更舒服。

项目结构我按功能划分，而不是按技术层次划分。根目录下建了Inference、Validation、Prompts、Knowledge、Controllers、Views这几个文件夹。Inference放推理服务封装，Validation放校验器，Prompts放模板文件，Knowledge放知识库访问代码。这样划分的好处是找代码的时候按功能找，不用在 Model、View、Controller 三个大文件夹里来回跳。

依赖方面，核心的 NuGet 包就几个：Microsoft.AspNet.Mvc、Newtonsoft.Json、Microsoft.Extensions.Http。没有引入太多第三方库，因为这套工程的核心逻辑都是自己写的，第三方库越多，出问题的时候排查链路越长。

配置文件里我把推理服务的地址、超时时间、重试次数都做成可配置的。推理服务的地址默认是本地回环，超时设的是 120 秒，因为本机推理在生成长文本的时候确实需要时间。重试次数设的是 2 次，再多的话用户体验太差。

4.2 推理调用链路的完整实现

一次完整的推理调用，从 Controller 接收到请求开始，到返回校验后的结果结束，中间经过了好几个环节。我把这条链路完整走一遍。

Controller 接收到用户输入后，先做输入规范化。这一步包括去除多余空白、统一标点符号、检测并拒绝明显无效的输入。输入规范化看起来不起眼，但能避免很多奇怪的问题。我遇到过用户输入里带了不可见字符，导致模型输出异常的情况，加了规范化之后就再没出现过。

规范化之后，调用上下文管理器组装 prompt。上下文管理器从会话存储里取出核心意图、近期对话和关键信息摘要，按模板填充。组装好的 prompt 会记录日志，方便后续排查问题。

然后调用推理服务，拿到原始输出。原始输出先过一遍格式校验，不通过的话触发一次重试，重试时会在 prompt 里追加格式约束的强调。重试还不通过，就返回一个降级结果，告诉用户当前无法生成符合格式要求的内容。

格式校验通过后，过事实校验和一致性校验。这两个校验不通过的话，不会直接重试，而是把校验发现的问题附在结果里一起返回，让用户决定是否采纳。因为事实和一致性的问题有时候是知识库本身不准导致的，直接重试可能越试越错。

最后把校验通过的结果返回给 View，同时把校验记录写入日志。日志里包含每次生成的 prompt、原始输出、校验结果和处理动作，这些日志是后续优化的重要依据。

4.3 流式输出的处理与前端渲染

本机推理的生成长文本的时候，如果等全部生成完再返回，用户要盯着空白页面等很久。所以我做了流式输出，模型每生成一段就推送到前端。

服务端这边，推理服务的接口支持流式返回，我用HttpCompletionOption.ResponseHeadersRead来读取流式响应，逐块解析后通过 SignalR 推送到前端。SignalR 的配置很简单，建一个 Hub，在 Hub 里维护连接和分组，推理过程中调用Clients.Group(groupName).SendAsync推送内容。

前端这边，用 JavaScript 建立 SignalR 连接，收到内容块就追加到显示区域。这里有个细节要注意，追加的时候不能直接操作 DOM 的 innerHTML，那样会导致页面重排，长文本的时候性能很差。我的做法是维护一个字符串缓冲区，用 requestAnimationFrame 批量更新，每帧更新一次，这样既流畅又不会卡。

流式输出还有一个好处是可以在生成过程中做实时校验。每收到一个内容块，就做一次轻量级的格式检查，如果发现格式已经跑偏了，可以提前中断生成，节省时间。这个提前中断的机制我实测下来能省不少等待时间。

4.4 知识库的构建与事实比对实现

事实校验依赖知识库，知识库的质量直接决定了校验的可靠性。我的知识库是用 SQLite 存的，结构很简单，就是实体、属性、值三列，加上来源和更新时间。

知识库的填充我做了两条路。一条是人工录入，针对核心的、高价值的领域知识，人工录入保证准确性。另一条是从现有文档里自动抽取，用规则加模型的方式抽取实体和关系，抽取结果先进入待审核队列，人工确认后才进入正式知识库。自动抽取的准确率大概在七成左右，所以必须有人工审核这一关。

事实比对的时候，我把输出里的实体抽取出来，在知识库里查对应的属性值，然后做比对。比对不是简单的字符串相等，而是做了归一化处理。比如数字的格式差异、同义词、缩写，都会先归一化再比对。归一化规则我维护了一个映射表，随着使用不断补充。

提示：知识库的更新要有版本记录，因为事实校验的结果会随着知识库变化而变化。如果出了问题要回溯，没有版本记录的话根本查不清是哪个时间点的知识库导致的。

5. 常见问题与排查技巧实录

5.1 推理服务无响应或超时

这是最常见的问题，表现是请求发出去之后一直等不到响应，最后超时。排查思路我总结了一个顺序。

先看推理服务进程还在不在。本机推理服务吃内存比较厉害，如果机器内存不够，进程可能被系统杀掉。用任务管理器看一下进程状态，如果没了就重新启动。

如果进程在，看它的日志。推理服务的日志里会记录每次请求的接收和处理情况。如果日志里根本没有收到请求，那问题出在通信链路上，检查端口是否被占用、防火墙是否拦截。如果日志里收到了请求但没处理完，那可能是模型加载出了问题或者输入太长导致推理卡住。

输入太长导致的卡住我遇到过好几次。模型对输入长度是有限制的，超过限制之后行为不确定，有时候会直接卡死。所以我在调用推理服务之前会先检查输入长度，超过阈值就做截断或者分段处理。

超时时间也要合理设置。我一开始设的是 30 秒，结果长文本生成经常超时。后来改成 120 秒，并且对超过 60 秒的请求做进度提示，用户体验就好多了。

5.2 生成结果格式不稳定

格式不稳定的表现是同样的 prompt，有时候输出符合格式，有时候不符合。这个问题的根源通常是 prompt 里的格式约束不够强，或者温度参数太高。

解决办法第一个是把温度降下来。温度越低，输出越稳定。我默认用 0.3，格式要求严格的场景会降到 0.1。

第二个是在 prompt 里用更强的格式约束。不要只说"输出 JSON"，而是给出完整的 JSON 示例，并且明确说"只输出 JSON，不要有任何其他文字"。示例的作用非常大，模型看到示例之后格式遵循度会明显提升。

第三个是加重试机制。格式校验不通过就重试，重试的时候在 prompt 里追加"上次输出格式不正确，请严格按照示例格式输出"。我实测下来，大部分格式问题在第一次重试就能解决。

5.3 事实校验误报的处理

事实校验误报是指把正确的输出判定为错误。这个问题比漏报更麻烦，因为误报会让用户对系统失去信任。

误报的主要来源是知识库不准确或者不完整。知识库里没有的实体，校验器无法判断，有时候会保守地判定为不通过。我的处理方式是引入"未知"状态，知识库里查不到的实体标记为未知，未知不触发不通过，只是记录在案。这样既避免了误报，又能通过未知实体的统计发现知识库的盲区。

另一个来源是归一化规则不完善。比如输出里说"大约一百"，知识库里是"100"，如果归一化规则没覆盖"大约"这种修饰词，就会误判。解决办法是持续补充归一化规则，把实际遇到的误报案例都转化成规则。

5.4 长文本生成的信息丢失

长文本生成的时候，中间部分的信息容易丢失或者被简化。这个问题的根源是模型在长生成过程中的注意力衰减。

我的应对方式是分段生成。把长文本任务拆成多个短任务，每个短任务生成后立即做校验，校验通过再生成下一段。分段的时候要注意段与段之间的衔接，我会在每段的 prompt 里附上上一段的结尾内容，保证连贯性。

分段生成会增加总的推理时间，因为每段都要重新加载上下文。但换来的是质量的可控性，我认为这个 trade-off 是值得的。对于质量要求不高的场景，可以不分段，直接一次生成然后做整体校验。

5.5 常见问题速查表

注意：排查问题的时候一定要先看日志，不要凭猜测去改代码。我见过太多人遇到问题就瞎改参数，结果把原本正常的部分也改坏了。日志里记录的信息比你想象的要多，养成先看日志的习惯能省大量时间。

6. 工程化落地的几点个人体会

这套工程我从最初的原型到现在稳定运行，前后迭代了十几个版本。有几个体会是踩了坑之后才明白的。

第一个体会是不要把 LLM 当成黑盒。很多人用 LLM 就是调个接口拿结果，出了问题完全不知道从哪查。我的做法是把推理链路的每个环节都记录下来，prompt 是什么、原始输出是什么、校验结果是什么、最终返回是什么，全都有日志。这样出了问题能精确定位到是哪个环节的问题。

第二个体会是校验比生成更重要。生成质量的上限由模型决定，但生成质量的稳定性由校验决定。一个中等能力的模型加上严格的校验，实际可用性可能比一个强模型不加校验还要高。因为用户能接受偶尔生成不出来，但不能接受生成错误的内容。

第三个体会是参数要可配置，不要硬编码。温度、最大长度、超时时间、重试次数这些参数，我全部做成了配置项。因为不同的场景需要不同的参数，硬编码的话每换一个场景就要改代码重新编译，效率太低。

第四个体会是知识库要持续维护。事实校验的效果完全取决于知识库的质量，而知识库不是建一次就完事的，需要在使用过程中不断补充和修正。我建了一个反馈机制，用户发现校验错误可以一键反馈，反馈会进入待处理队列，定期处理。

这套工程后续还可以往几个方向扩展。一个是加入多模型路由，根据任务类型自动选择最合适的模型。另一个是加入生成结果的自动评分，用另一个模型对生成质量打分，低分结果自动触发重试。还有一个是把校验器做成插件式，方便针对不同领域定制校验规则。这些扩展我还在陆续做，有新的进展再分享。