ساخت مغز سازمانی با RAG برای صنعت فولاد
یکی از مشکلات قدیمی سازمانها این است که دانش دارند، اما نمیدانند کجاست.
یک فایل روی لپتاپ فروش.
یک PDF در پوشه فنی.
یک تجربه در ذهن مدیر خرید.
یک جواب مهم در پیامهای تلگرام.
یک استاندارد در ایمیل.
و چند سال تجربه در ذهن آدمی که اگر فردا نباشد، بخشی از حافظه شرکت هم با او میرود.
این برای من همیشه مسئله بزرگی بوده.
مخصوصاً در صنعت فولاد که یک سؤال ساده گاهی پشتش چند لایه دانش فنی و تجاری است.
معادل یک گرید چیست؟
برای یک کاربرد خاص چه گزینههایی داریم؟
مشتری قبلاً چه چیزی خریده؟
آنالیز مورد نیاز چیست؟
تجربه قبلی تیم درباره این تأمینکننده چه بوده؟
اگر جواب هر سؤال به یک نفر خاص وابسته باشد، سازمان کند میشود.
و اگر همان آدم نباشد، سازمان فراموشکار میشود.
اینجا بود که مفهوم RAG برای من از یک اصطلاح فنی تبدیل شد به یک نیاز واقعی کسبوکار.
RAG در سادهترین نگاه یعنی مدل هوش مصنوعی قبل از جواب دادن، اطلاعات مرتبط را از دانش خود سازمان پیدا کند.
یعنی به جای اینکه فقط به حافظه عمومی مدل تکیه کند، اول سراغ اسناد و دادههای واقعی تو برود.
این فرق مهمی است.
چون در کسبوکار صنعتی، جواب خوب فقط جواب روان نیست.
باید به اطلاعات درست متکی باشد.
اگر درباره یک فولاد آلیاژی حرف میزنیم، باید منبع مشخص باشد.
اگر درباره رویه داخلی حرف میزنیم، باید آخرین نسخه رویه را ببیند.
اگر درباره مشتری حرف میزنیم، باید اطلاعات همان مشتری را بخواند.
اینجا دیگر چتبات عمومی کافی نیست.
باید حافظه سازمانی بسازیم.
اما ساخت RAG فقط ریختن چند PDF داخل یک پایگاه برداری نیست.
این شاید بزرگترین سوءتفاهم درباره پروژههای دانش سازمانی باشد.
اولین مسئله کیفیت منبع است.
اگر اسناد تکراری باشند، جواب تکراری میگیری.
اگر نسخه قدیمی و جدید کنار هم باشند، مدل ممکن است هرکدام را انتخاب کند.
اگر متن ناقص باشد، بازیابی هم ناقص میشود.
اگر دستهبندی نداریم، پیدا کردن سند مناسب سختتر میشود.
پس قبل از Embedding، باید خانهتکانی دانش انجام شود.
من دوست دارم منابع را مثل موجودی انبار ببینم.
هر چیزی باید شناسه داشته باشد.
موضوع داشته باشد.
نسخه داشته باشد.
مالک داشته باشد.
و معلوم باشد فعال است یا منسوخ.
وقتی این نظم نباشد، RAG فقط آشفتگی را قابلجستوجو میکند.
مرحله بعد خرد کردن دانش است.
یک فایل صدصفحهای برای مدل مثل یک انبار بزرگ بدون قفسهبندی است.
باید محتوا به قطعات منطقی تقسیم شود.
نه خیلی کوچک که معنی از بین برود.
نه خیلی بزرگ که بازیابی دقیق نباشد.
این بخش ساده به نظر میرسد، اما کیفیت پاسخ را شدیداً تغییر میدهد.
بعد نوبت Metadata است.
موضوع.
نوع سند.
تاریخ.
واحد سازمانی.
منبع.
سطح اعتبار.
نسخه.
این اطلاعات کمک میکند فقط نزدیکترین متن را پیدا نکنیم.
درستترین متن را پیدا کنیم.
برای من این فرق مهم است.
Similarity به تنهایی حقیقت نیست.
ممکن است متنی خیلی شبیه سؤال باشد اما منبعش قدیمی یا کماعتبار باشد.
پس RAG خوب باید علاوه بر شباهت، منطق کسبوکار هم داشته باشد.
یکی از چیزهایی که برای پروژههای سازمانی مهم میدانم، تأیید انسانی دانش است.
هر چیزی که وارد پایگاه دانش میشود نباید خودکار معتبر فرض شود.
بهخصوص اگر از منابع خارجی جمعآوری شده.
بهتر است یک مسیر تأیید وجود داشته باشد.
تأیید.
رد.
نیاز به توضیح.
این کار سرعت ورود اطلاعات را شاید کمی کم کند، اما اعتماد به خروجی را بالا میبرد.
و اعتماد برای سیستم دانشی حیاتی است.
اگر کاربر دو سه بار جواب غلط بگیرد، دیگر از سیستم استفاده نمیکند.
حتی اگر صد جواب بعدی درست باشد.
مسئله بعدی منبعدهی است.
من دوست ندارم دستیار فقط جواب بدهد.
باید بتواند بگوید این جواب از کجا آمده.
نام سند.
بخش مرتبط.
تاریخ یا نسخه.
این باعث میشود AI از جعبه سیاه فاصله بگیرد.
کاربر میتواند بررسی کند.
در موضوعات فنی، این قابلیت خیلی مهم است.
مثلاً وقتی درباره عملیات حرارتی، خواص مکانیکی یا معادل استاندارد صحبت میکنیم، باید بتوانیم به منبع برگردیم.
یک مغز سازمانی خوب فقط جوابدهنده نیست.
یادگیرنده هم هست.
اگر سؤال جدیدی تکرار میشود و جواب در دانش نیست، باید آن را ثبت کند.
اگر کاربران مداوم یک پاسخ را اصلاح میکنند، باید بفهمیم منبع نیاز به بازبینی دارد.
اگر یک سند زیاد استفاده میشود، ارزشش مشخص میشود.
این یعنی RAG باید به چرخه مدیریت دانش وصل باشد.
نه اینکه یکبار ساخته شود و بعد رها شود.
در صنعت فولاد این موضوع جذابتر هم میشود.
چون دانش فقط فنی نیست.
دانش فروش هم هست.
اعتراضهای مشتری.
سؤالهای پرتکرار.
تجربه مذاکره.
شرایط تأمین.
ریسکهای حمل.
فرآیند داخلی.
همه اینها میتوانند بخشی از حافظه سازمان باشند.
وقتی این دانش به هم وصل شود، دستیار فقط درباره فولاد جواب نمیدهد.
درباره نحوه کار خود سازمان هم میفهمد.
این همان چیزی است که من از «مغز سازمانی» میخواهم.
نه یک چتبات با ظاهر زیبا.
یک حافظه قابلجستوجو، قابلاعتماد و قابلرشد.
پشت صحنه ممکن است Qdrant باشد.
ممکن است PostgreSQL باشد.
ممکن است n8n اطلاعات را وارد کند.
ممکن است مدل زبانی پاسخ را بسازد.
اما برای کاربر همه اینها باید یک تجربه ساده باشد.
سؤال میپرسد.
اطلاعات مرتبط پیدا میشود.
پاسخ ساخته میشود.
منبع نشان داده میشود.
اگر اطمینان پایین است، سیستم باید صادقانه بگوید.
این قسمت آخر خیلی مهم است.
هوش مصنوعی نباید وانمود کند همیشه میداند.
گاهی بهترین جواب این است:
منبع کافی ندارم.
نیاز به بررسی انسانی است.
برای من، RAG زمانی موفق است که سازمان کمتر وابسته به حافظه افراد شود، بدون اینکه تجربه افراد را بیارزش کند.
تجربه آدمها باید تبدیل به دارایی سازمان شود.
ثبت شود.
ساختار بگیرد.
قابلبازیابی شود.
و نسل بعدی تیم بتواند از آن استفاده کند.
اگر این اتفاق بیفتد، هوش مصنوعی فقط یک ابزار جدید نیست.
تبدیل میشود به لایهای برای حفظ و انتقال حافظه سازمان.
و برای صنعتی مثل فولاد که تجربه سالها ارزش دارد، این شاید یکی از مهمترین کاربردهای واقعی AI باشد.
One of the oldest organizational problems is having knowledge without knowing where it lives.
A file on a salesperson’s laptop.
A PDF in the technical folder.
An important lesson in the purchasing manager’s head.
A useful answer buried in Telegram messages.
A standard hidden in email.
And years of experience inside one person who may take part of the company’s memory with them when they leave.
This has always felt like a serious problem to me.
Especially in steel, where a simple question can sit on top of several layers of technical and commercial knowledge.
What is the equivalent of this grade?
What options fit this application?
What did this customer buy before?
What analysis is required?
What has the team learned about this supplier?
If every answer depends on one specific person, the organization becomes slow.
And when that person is absent, the organization becomes forgetful.
That is where RAG became more than a technical term for me.
It became a real business requirement.
In simple terms, RAG allows an AI model to retrieve relevant information from the organization’s own knowledge before answering.
Instead of relying only on the model’s general memory, it first looks at your actual documents and data.
That difference matters.
Because in industrial business, a good answer is not simply a fluent answer.
It needs to be grounded in the right information.
If we are discussing an alloy steel grade, the source needs to be clear.
If we are discussing an internal procedure, the system should use the latest version.
If we are discussing a customer, it should read information about that customer.
A general chatbot is not enough for this.
We need organizational memory.
But building RAG is not simply throwing PDFs into a vector database.
That may be one of the biggest misunderstandings around organizational knowledge projects.
The first problem is source quality.
If documents are duplicated, retrieval becomes noisy.
If old and new versions live together without structure, the model may choose either.
If text is incomplete, retrieval will be incomplete.
If there is no classification, relevant information becomes harder to find.
So before embeddings, knowledge needs housekeeping.
I like to treat knowledge sources the way we treat physical inventory.
Every item should have an identity.
A topic.
A version.
An owner.
And a status showing whether it is active or obsolete.
Without that discipline, RAG only makes chaos searchable.
The next step is chunking.
A hundred-page document can be like a warehouse with no shelving.
Content needs to be divided into logical units.
Not so small that meaning disappears.
Not so large that retrieval becomes imprecise.
This sounds simple, but it has a major effect on answer quality.
Then comes metadata.
Topic.
Document type.
Date.
Department.
Source.
Authority level.
Version.
Metadata helps us retrieve not only the most similar text.
It helps us retrieve the most appropriate text.
That distinction matters to me.
Similarity alone is not truth.
A passage can be highly similar to the question while coming from an outdated or low-authority source.
A good RAG system needs business logic in addition to semantic similarity.
Human approval is another part I consider important in organizational knowledge systems.
Not everything entering the knowledge base should automatically be treated as trusted.
Especially when knowledge is collected from external sources.
A review path is valuable.
Approve.
Reject.
Needs clarification.
This may slow ingestion slightly, but it increases trust in the final answers.
And trust is critical for knowledge systems.
If users get two or three wrong answers, they may stop using the system.
Even if the next hundred answers would have been correct.
Then there is sourcing.
I do not want an assistant that only gives an answer.
It should be able to show where the answer came from.
The document name.
The relevant section.
The date or version.
This moves AI away from being a black box.
Users can verify.
In technical subjects, that matters greatly.
When discussing heat treatment, mechanical properties, or standards equivalence, we should be able to return to the source.
A good organizational brain does more than answer.
It learns.
If a new question appears repeatedly and the knowledge does not contain the answer, that should be recorded.
If users repeatedly correct one answer, the source may need review.
If one document is used constantly, its value becomes visible.
That means RAG should connect to a knowledge-management cycle.
It should not be built once and abandoned.
In steel, the opportunity becomes even more interesting.
Knowledge is not only technical.
There is sales knowledge too.
Customer objections.
Frequently asked questions.
Negotiation experience.
Supply conditions.
Logistics risks.
Internal processes.
All of those can become part of organizational memory.
When that knowledge is connected, the assistant does not only answer questions about steel.
It also understands how the organization works.
That is what I mean by an ‘organizational brain.’
Not a chatbot with a beautiful interface.
A searchable, trustworthy, growing memory.
Behind the scenes, it may use Qdrant.
It may use PostgreSQL.
n8n may handle ingestion.
A language model may construct the answer.
But to the user, the experience should remain simple.
Ask a question.
Retrieve relevant information.
Build the answer.
Show the source.
And when confidence is low, say so honestly.
That last part matters.
AI should not pretend it always knows.
Sometimes the best answer is:
I do not have enough reliable source material.
Human review is required.
For me, RAG succeeds when the organization becomes less dependent on individual memory without making human experience less valuable.
People’s experience should become an organizational asset.
Recorded.
Structured.
Retrievable.
And usable by the next generation of the team.
When that happens, AI is no longer just another tool.
It becomes a layer for preserving and transferring organizational memory.
And in an industry like steel, where years of experience carry real value, that may be one of AI’s most practical uses.