반응 표면 방법론에 관한 질문(Box-Behnken 설계 매트릭스)좋은 아침,
저는 현재 구체적인 Box-Behnken 디자인 매트릭스에서 반응 표면 방법론을 사용하여 일부 효소 반응을 최적화하려고 노력하고 있습니다.
프로그램을 사용하여 독립 변수 또는 요인(pH, 온도, 효소 부하 등)을 선택하고 각각에 "낮음" 및 "높음" 값을 할당합니다. 그러면 프로그램이 자동으로 "중간" 값을 계산합니다.
첫 번째 질문은 "중간" 값을 변경할 수 있는지 여부입니다. 효소 부하에 대한 Mi 낮은 값은 5 U/mL이고 나의 높은 값은 20입니다. 따라서 중간점은 12.5 U/mL이어야 합니다. 그러나 나는 10 U/mL로 "중간" 반응을 수행했습니다. 이 프로그램을 사용하면 제안된 값을 매우 쉽게 변경할 수 있으므로 그렇게 했습니다. 이것에 문제가 있습니까? 프로그램이 이러한 변경을 허용한다면 12,5 대신 10 값을 사용했다는 점을 고려하여 반응 조건을 최적화할 것이라고 가정합니다.
다음 질문은 프로그램에서 제안한 것보다 더 많은 반응(요인의 다양한 조합 포함)을 추가할 수 있는지 여부입니다. 이것은 프로그램으로 실험을 설계하기 전에 몇 가지 반응을 수행했고 프로그램에서 제안한 것과 다른 변수 조합에서 수행된 반응에 대한 결과("반응")를 가지고 있기 때문입니다. 실험 계획이 프로세스 최적화에 필요한 반응 수를 최소화하기 위한 것임을 알고 있지만 이미 이러한 값을 가지고 있기 때문에 예측 모델을 더 강력하게 만드는 데 유용할 수 있다고 생각합니다.
고급에 대단히 감사합니다.
카를로스
암사슴Re: 응답 표면 방법론에 관한 질문(Box-Behnken 설계 매트릭스)요인 공간의 중간에 있지 않은 장소에 '중간' 값을 넣었다고 DOE 감옥에 갇히지는 않을 것입니다. 이것은 약간의 '유해'하고 디자인의 직교성에 대해 사용하기에는 너무 강한 단어일 수 있지만 일반적으로 치명적인 결과는 아닙니다.
설계 공간에 추가 실행을 추가하는 것은 절차적 관점에서 JMP에서 매우 수행할 수 있습니다. 하지만 이와 함께 진행해야 하는 몇 가지 가정이 있습니다. 예를 들어 성가신/노이즈 변수의 존재 여부 및 코어 사이의 영향 디자인 및 추가 실행. 당신의 직감은 이것에 대해 무엇을 말합니까...예를 들어, 핵심 설계에서 아마도 한 공급업체의 재료를 사용하고 있을 수 있습니다... 그리고 다른 실행에서는 다른 공급업체를 사용했습니다. 공급자 재료 차이로 인한 영향이 없다고 가정하시겠습니까?
이러한 추가 실행은 또한 핵심 설계에서 효과의 상관 관계에 추가로 영향을 미치며 예상하지 못한 추정치 간에 일부 상관 관계를 만들 수 있습니다. 따라서 분석을 진행하기 전에 디자인 비교 플랫폼을 사용하여 이러한 런을 추가하는 효과를 평가할 수 있습니다. 플러스 크기에 대한 다른 모든 조건이 동일하면 병합된 디자인의 성능이 높아져야 합니다.
Re: 응답 표면 방법론에 관한 질문(Box-Behnken 설계 매트릭스)피트의 조언이 맞습니다. 몇 가지 추가 생각이 있습니다...완전히 겸손한 의견이므로 무시하셔도 됩니다.
1. 설계된 실험은 독립 변수 간의 인과 관계를 이해하는 효과적이고 종종 효율적인 수단을 제공하기 위한 것입니다. 강력한 모델이 있다고 판단되면(노이즈 조건 변경에 대해 실험했으며 결과가 일관적임) 응답 표면을 더 자세히 이해할 수 있습니다. 이것은 디자인 공간의 충분한 "채움"을 제공하는 하나의 디자인에서 또는 "추가적인" 순차적 디자인에서 수행될 수 있습니다(박스 접근 방식). Box Behnken 설계는 극한에서 실행할 수 없는 요인에 특히 유용하므로 극단은 설계에서 제외됩니다.
2. 10(5와 15)의 중심점에서 - 및 +를 단순히 등거리에 두지 않는 이유가 확실하지 않습니까? 균형 잡힌 설계는 분석하기 쉽고 편향이 적습니다. 그러나 당신에게 가장 의미 있는 일을 하십시오.
3. 피트가 맞습니다. 어제는 작동했지만 내일은 작동하지 않는 복잡한 모델을 개발하는 것은 좋지 않습니다.
4. 매핑하려는 복잡한 표면의 관점에서 생각합니다. 저도 그렇게 분석하겠습니다. 통계적 유의성을 이미 알고 있으므로(1차 모델이 있어야 함) 이제 미세 조정 중입니다. 복잡성이 반드시 좋은 것은 아니지만 멋지긴 합니다. 모델은 관리할 수 있어야 합니다.
